在即将过去1年，我从开始尝试用AI编程工具实现产品需求，到完全Vibe Coding。

这个过程让我意识到：掌握AI不是学会提问，而是学会指挥。

今天就分享我这一年总结的21条实践法则，也是我个人实践的阶段性总结。

需要坦诚地说，这些经验具有时效性，因为Coding Agent的迭代速度极快。

如果其中有对你有启发的思路，这份分享就有了意义。

第一章：指挥官的心法

1. 你是产品经理兼架构师，不是打字员

不要陷入语法细节。你的核心能力应该用于定义"是什么（What）"和"为什么（Why）"，把"怎么做（How）"留给AI。

实践建议：宏观阶段，我会用Repomix + AIStudio与AI充分讨论规划。微观上，每次新任务都让AI先给出技术方案和实施步骤，待我审核理解后再实施。

2. 代码是负债，功能才是资产

AI容易生成冗余代码。代码越多，维护成本越高。你需要敢于让AI删除代码，敢于拒绝"过度设计"。

实践建议：读完AI的技术方案后，直接反问："你是否过度设计了？""是否充分复用已有组件？"与其先生成再删除，不如从源头规避冗余。

3. 只有"已验证的"才是"已完成的"

AI总是自信地生成错误代码。未经运行或测试的代码，默认为0分。"信任，但要验证（Trust, but Verify）"是最高法则。

实践建议：自动化测试非常关键。但要注意——某些能生成代码的LLM写不好测试用例。检验其能力的标准是：它的测试用例是在制造更多报错，还是发现了业务漏洞？修复Bug时是准确诊断问题，还是为了让用例通过而改写业务逻辑？

4. 保持"无情"的抛弃感

如果AI把代码改得一团糟，不要修补。直接回退到干净的版本，或删掉整个文件重来。沉没成本在AI编程中不存在。

实践建议：必须使用Git做版本管理。推荐手动执行git clean/git checkout，谨慎提出删除文件的指令。

5. 你的品味决定了天花板

AI的水平是互联网代码的平均值。如果你的审美（架构、代码风格）不够高，AI会把你拉向平庸。你必须用品味去约束它。

实践建议：经验丰富的程序员在此处能找到自己的价值——不让平庸代码流入产品。对于新手全栈，建议补齐编程基础书籍和架构思维。

第二章：交互与提示工程

6. 自然语言是新的编译器

Prompt的清晰度决定代码质量。不要说"优化一下"，要说"将此函数拆分为三个子函数，分别处理X、Y、Z，并增加错误捕获"。

实践建议：随着LLM能力提升，这条规则的重要性在下降。对于高能LLM，可以用模糊需求，让它给出清晰方案并按优先级罗列。这有点像"开宝箱"，时不时有惊喜——需配合第1条军规使用。

7. 上下文是王道（Context is King）

AI犯蠢通常是因为没看到该看的文件。精准地@相关文件、文档或接口定义。喂给它正确的信息比问它正确的问题更重要。

实践建议：此原则总是有效。但实践中还要考虑LLM的context窗口大小和Coding Agent的实现。项目早期或高能Agent可以不需精准提及。对于复杂项目或想省tokens，就精准一些。

8. 所有Prompt都是一次测试驱动开发（TDD）

先告诉AI预期的输入和输出（Test Case），再让它写实现。这能降低幻觉率约50%。

实践建议：即使高能Agent的幻觉已显著降低，TDD思想仍然好用。

9. 维护项目规则文件（.cursorrules或agents.md）

把你的代码风格（TypeScript interface vs type、Tailwind vs CSS等）写进项目根目录规则文件。让AI进门先背家规。

实践建议：可以让AI帮你书写并更新这份规则文件。这是统一风格、减少审查工作的有效方式。

10. "一步一步来"（Step by Step）依然有效

不要让AI"重构整个后端"。让它"先提取API接口定义"→"确认无误后实现Controller"→"最后写Service"。原子化任务成功率最高。

实践建议：与Coding Agent的能力相关。若严格遵循第1条，这条属于冗余。

第三章：熵减与架构控制

11. 小文件主义（Small Files Principle）

AI在处理几千行大文件时智商会掉线。将代码极度模块化，每个文件控制在200-800行以内（我的标准线是800行，200行可能陷入过度抽象）。

实践建议：这既利于AI理解，也利于人类Review。

12. 类型系统是你的安全网

强类型（TypeScript/Rust/Go）是AI编程的最佳伴侣。类型检查能挡住80%的AI低级错误（如字段名瞎编）。先写类型定义，再让AI填空。

实践建议：使用pre-commit钩子，前后端一键lint，能显著提升开发幸福度。

13. 文档驱动开发（DDD - Documentation Driven Development）

先让AI写README或接口文档。你确认逻辑通顺后，再让它根据文档写代码。文档即是蓝图。

实践建议：我个人倾向弱化纯技术文档，因为文档和代码存在不一致风险。文档用于承载设计思想与架构规划，尽量少涉及技术细节。

14. 提交必须原子化（Atomic Commits）

AI编程速度极快，很容易一小时产生大量修改。高频Commit，每次只做一个功能点。否则出Bug时根本不知道哪次"Vibe"出了问题。

实践建议：我倾向于维护一个人类验收过的稳定主干，把每个新特性用新分支开发，在1天至1周内完成代码、验收并合并回主干。

15. 警惕"幽灵依赖"

AI喜欢引入它见过但你项目中没安装的库。在npm install或pip install之前，检查一下它引入了什么。

实践建议：与AI充分讨论技术栈选择，让它写入README。对每次可能引入新库的需求，都让它结合已有栈，选择稳定、成熟的库。定期清理冗余代码和依赖。

第四章：人类的底线

16. 不要让大脑萎缩

阅读AI生成的代码。如果你看不懂那段代码在干什么，绝对不要合并。否则两周后就是不可维护的黑盒。

实践建议：对于原本不编程的人，读懂代码的门槛并不高——你已从语法中解脱，可像阅读自然语言般阅读代码。但对原本有编程能力的人，容易陷入"既懂又不够懂"的感觉，因为会大量接触从未写过的代码和库。这需要有意识地保持学习。

17. 关注边缘情况（Edge Cases）

AI是"快乐路径（Happy Path）"的专家，默认一切顺利。你必须既是架构师，也是QA，专门问它："网络断了怎么办？""用户输入为空怎么办？"

实践建议：对快速写原型的人无需过度考虑；对做正经产品的团队，这属于基本常识。

18. 安全审查是你的责任

AI可能把API Key硬编码，或写出SQL注入漏洞。它是天真的，你是世故的。

实践建议：可以让Coding Agent执行安全审查、罗列风险并消除它们。

19. 警惕"死循环对话"

如果与AI对话超过5轮还在纠结同一个Bug，停下来。AI已陷入局部最优解的陷阱。人工介入，手动修改，或换个思路重开对话。

实践建议：特别是按量烧tokens的人应留意。大多数任务几分钟到十几分钟就能完成，不要离屏过久。

20. 只有你能定义"完成"

AI可以永远优化下去。你必须有清晰的"Definition of Done"。功能跑通？性能达标？UI对齐？到了标准就停手。

实践建议：人类掌握着"度"，这是AI所不具备的。

21. 享受心流，但手握方向盘

AI编程的快感在于"极速实现"。享受这种魔法，但时刻记住：如果车毁人亡，司机是你，不是AI。

实践建议：人类是最终的背锅侠，这正是人类在AI时代的价值所在。

结语

这21条法则的核心逻辑其实很简单，AI是执行层，人是决策层。

越来越多的产品经理和非职业开发者开始用AI编程实现想法，这本身没什么问题。

但问题在于：

• 不能把AI当"代码生成机"，而要当"技术助手"
• 不能逃避架构思维，反而要强化它
• 不能放弃最后的质检权，这是人类的最后堡垒

我从PM出身，所以对"验证"这件事格外敏感。

这一年我用AI编程的经历让我意识到，未来的"全栈"不再是技术全能，而是能指挥AI、能定义完成标准、能承担最终责任的人。

如果你正在学习AI工具，希望这些经验能给你一些参考。

同时欢迎在实践中不断迭代这些法则——因为AI的变化足够快，我们的方法论也需要足够灵活。