最近两个月做了大量使用AI进行编码的尝试，对AI编辑器（ClaudeCode/CatPaw/Kiro/Qoder/Wrap）、流程约束（CursorRules/OpenSpec/Speckit）和辅助工具（Skills/SubAgent/Agents.md）进行了探索调研，得到目前我认为实用且有效的一些方法和技巧分享给大家。

先明确一下以下观点：
* 难度排序：做新的 > 参考已有做新的 > 在已有的做修改，且在现有LLM能力下，原来需要人工编程工作量在2pd的基本借助AI可在半天完成90%以上的代码编写，且全程基本不需要人的额外约束和介入。
* Specs拆分合理对编码质量有决定性作用，输入质量决定了输出质量，需求中间specs产物甚至比大模型能力要重要，采用清晰合理的任务拆分给flash或haiku得到的效果比Sonnet或Opus要好，就好比你把答案通过Specs的形式提前泄露给成绩一般的学生，那他们的考试成绩可能就比不知道答案的好学生要好，但也有例外，实践过程中gemini-3-pro强得可怕，在一次测试中没有Specs的编码结果甚至比有Specs的对照组结果好，就好比顶级学生不知道答案也比提前知道部分答案的普通学生考试成绩好得多。目前主流编辑器都实现了Plan模式，做到了类似OpenSpec和Speckit的形式，但各家提示词的差异也决定了产出质量，实践下来的结论：Specs实现（Kiro/OpenSpec/Speckit） > Plan模式 > 普通模式，且Kiro的系统提示词表现最佳，可以将需求明确和拆分得更精准。
* 在之前的文章中也明确了，提示词不是越多越好，AI编码在复杂任务的表现不佳很大程度上是因为Context爆炸导致关注点缺失，从而降低了编码完整性，这点在我们测试过程中采用SubAgent剥离上下文，或者复杂需求拆分为中小需求，或者采用spec-driven将任务颗粒度拆到足够小等方式都可以获得更好的AI编码结果。 
* 给出项目背景信息和之前的人工代码实现给AI参考后，编码效果得到提升，但特殊要求如需要严格复用之前某个代码，需要在流程Spec或AI Agent提示（Claude.md/Agents.md）中给于说明以便AI应用。
* Skills是目前承载约束和说明的最佳实践。采用MCP同样可以拆分命中解决Context Size问题，但Skills的组织方式更为灵活和方便管理，如组件库的说明可以采用MCP分组件说明Props，10 个组件就是 10 份文档，即使这次只用了一个按钮，MCP调用过程需要经过列出可用组件->寻找按钮->查看所有的Props->按本次需求分析如何组织使用->翻译为本次需求代码，而Skills可以通过name和description直接命中本次需要的组件，内容上更多呈现业务场景需要的组合使用，更符合业务需要。MCP 只能表达“你能用什么”，而 Skills 表达的是“你应该怎么用、用成什么样”。后者正是模型调用最缺的“行为约束”。


目前最佳实践
* 项目级定义背景信息和知识：使用AI总结当前项目的业务背景、代码结构、通用组件和技术栈等背景信息，用于后续编码实现时复用和参考现有代码，以及避免使用了不兼容的代码实现，如Optional Chaining(?.)语法在Vue2.x的模板中是不被支持的，不约定清楚会导致项目无法运行。通常这一步使用AI生成即可，如Claude Code中输入`/init`指令即可。
* Skills约束AI怎么做编码实现：SDD的编码实践仍然是目前大型项目做复杂需求迭代保证正确性和可维护性的最佳范式，我们将需求澄清、技术设计、任务拆分和编码实现分别作为skill，对关键过程这样做可以保障确定性。如果不知道该怎么实现，参考我之前分享的各AI编码工具的提示词有个GitHub仓库。编码实现skill最为关键，可以将Claude.md中没有明确、更好的实现方式或者更多的要求都作为内容以便AI的正确Coding。 
* Agents.md确保前面两步的内容用得上: 一般Skill是通过AI Agent命中description智能命中的，但如果需要确保我们精心设计的skill在流程中必须命中，直接通过提示词写明即可。openskills 的 sync 命令就是直接将name和description直接添加到Agents.md中从而保证skill的识别的调用的。

后续策略
* 按工作量适配流程：大的需求采用更为复杂的流程，小的需求采用更为简化的流程，但需要做到最小可用，有些东西是通用的。
* 后面的需求实现需要参考前面的需求实现：需求specs应该被积累和后续调用。
* skills要做到自主更新：在makepad的skills中我看到可以通过Claude Code预留的Hooks做修改后自动更新对应的skill内容，我们就可以不手工维护md内容了，而是在AI修改一堆报错后反思应该怎么修改内容从而使下次不再写出类似有错误的代码。
* 融入一些有用的工具：PRD文档、接口文档和设计图都应该能被读取，减轻SDD流程中人介入修改的工作量。也可以将社区中类似Ralph-loop这样有用的Skill集成到我们的实践流程中。
* 结合TDD（Test Driven Development）应对研发环节的左移：前置和后置都应该有测试环节的接入，有了前置测试Case编码实现会比需求specs更为准确，后置的UI和单元测试接入AI Agent可以更智能化，不依赖人去做CodeReview和界面功能验收，而是Agent自己知道哪里有问题自己进行代码调整。

#aicoding##speccoding#