让 AI 编程更可靠的项目协作习惯

用 AI 写代码，收益最大的改进一定是换模型吗？作者独自用 Claude Code 开发印度点对点停车位交易平台 ParkEase，持续五周后，给出了另一个答案：围绕模型建立规则、记录和验证流程，比纠结模型选择更有用。

他整理了 12 个习惯，覆盖动手前、开发中和交付前。它们值得程序员借鉴，但证据边界也很清楚：这是一个项目的实践复盘，没有模型对照实验，也没有量化每项习惯的收益。

先把决定留下来，才能减少反复沟通

作者把收益最高的习惯放在了第一条：准备一份 Agent 每次会话都会读取的指令文件，写明技术栈、最重要的 5 到 10 条规则，以及禁止事项。例如「Drizzle, NOT TypeORM」，可以避免每次重新争论数据库工具。

规则之外，还要记录架构决策及其原因。ParkEase 的例子包括：金额使用整数 paise，也就是印度卢比的辅币单位；重复预订由数据库约束阻止。如果只留下实现代码，Agent 下次可能重新推理，得出另一个同样看似合理的方案。

这里有三类信息，作用各不相同：

• 指令文件告诉 Agent，接下来必须遵守什么。
• 决策记录解释，现有方案为什么这样设计。
• 经验文件保存，哪些问题曾经花了大量时间排查。

作者的具体门槛是：一次修复超过 15 分钟，就记入经验文件；同一个纠正说了两次，第二次就应该进入指令文件。

需要反复遵守的要求，应当留在仓库里。

这不能保证 Agent 永远照做，但能让下一次会话有东西可读，减少靠聊天记录维持一致性的负担。

写得更快之前，先减少猜测和多余实现

作者建议，每个功能开始前先讨论方案，把任务描述里没回答的问题找出来。接着再问一句：这个东西真的需要存在吗？

这两步分别处理不同问题。前者补需求缺口，后者控制范围。AI 很容易把一个小需求扩展成多层抽象和额外组件，提前删掉不必要的设计，通常比实现后再重构省事。

调用库之前，也要先查文档和类型定义。作者观察到的高成本循环是：猜一个 API，失败，再猜一个。增加「先读再写」的规则后，他认为整段重试过程明显减少了，但没有给出次数或耗时对比。

视觉需求则适合直接看结果。作者会让 Agent 渲染 2 到 3 个方案，再从中选择。对前端开发而言，这比反复解释「更紧凑一点」「更有层次」更容易形成共同判断。

并行也需要控制。作者曾在一项任务中分出 5 个 Agent，每个都重新建立上下文，消耗了接近一周的大部分使用额度。他的建议是，把专业分工留给值得单独审查的改动，别让并行成为默认动作。

测试通过之后，还差一次真实运行

作者主张先写失败测试，再补实现；集成测试连接容器里的真实数据库，减少对模拟对象（mock）的依赖。他担心的是：mock 也可能带着同一套错误假设，最终只证明两份实现彼此一致。

但真实数据库测试仍然不等于交付验证。

ParkEase 的所有测试都通过时，仍有 3 个 bug 进入首次部署。作者启动构建好的镜像并实际点击操作，几分钟就发现了它们。原文没有说明这 3 个 bug 的具体原因，因此不能据此判断是哪类测试缺失。

这也是他强调「证据」的原因。「已经充分测试」无法复核，测试命令及其输出才可以；完成前验证，应当成为固定步骤。

审查也要缩小问题范围。与其让 Agent 泛泛地「审查代码」，不如明确要求查找被吞掉的错误，或检查哪些查询缺少索引。检查目标越具体，越容易确认它到底查了什么。

我的判断

这套做法最有价值的地方，是把需求、决策和验收条件变成可检查的材料。相比不断补充聊天提示，它更容易被下一次会话和团队其他成员复用。

不过，「比任何模型升级都有用」仍然是经验判断。作者没有披露模型版本、对照实验或各项习惯的收益数据，12 条习惯的排序也只是大致排序。

真实基础设施测试同样需要取舍。数据库约束和事务行为适合连接真实数据库验证；纯函数、组件状态等逻辑，仍可通过单元测试或受控 mock 快速检查。原文对 mock 的批评有提醒作用，却不足以证明所有 mock 都应该移除。

另外，作者是独立开发者。团队使用这些文件，还需要有人维护、去重和处理规则冲突，否则经验越积越多，也可能变成过时指令。至于他提出的软件开发生命周期正在转向 AI 开发生命周期，原文只是预告观点，没有展开论证。

能拿来做什么

• 给日常 AI 编程准备一份简短的仓库指令，先写技术栈、禁止事项和验收要求；重复出现的纠正及时补进去。
• 开发涉及金额、预订或数据库约束的 Node 服务时，记录决策原因，并让关键集成测试连接容器里的真实数据库。
• 做前端视觉需求时，先渲染 2 到 3 个可比较的方案；交付前启动真实构建产物，走一遍主要操作路径。
• 给 Agent 的完成标准加上可复核证据，要求提供实际执行的测试命令和输出，再按错误处理、查询索引等明确范围分别审查。