在 2026 年 2 月至 10 月期间，一位不会写代码的产品负责人使用 Claude Code 开发自己的产品 SiteNeuro。项目累计产生 3,215 次提交、1,156 个已合并 Pull Request，持续 175 个工作日。平台上线两个月后，已经构建了超过 1,000 个网站。
这段经历真正值得关注的地方，不是 AI 写了多少代码，而是当项目规模超过单次聊天所能承载的范围后，一个非开发者如何判断哪些变化可以接受、哪些风险需要拦住、哪些错误必须能退回。文章给出的方法并不依赖逐行读代码，而是把规则、规格、测试和回滚能力逐步沉淀到代码仓库中。
第一道护栏：把记忆从聊天搬进仓库
作者发现，纯聊天驱动的开发在项目变大后会出现一类可预测的问题：决策散落在聊天记录里，聊天会遗忘；后续修复可能与已有约束冲突；每个新会话都要重新解释上下文。解决方案不是等待更强的模型，而是把项目必须遵守的记忆移到仓库里，让 AI 编程助手在开始时自动读取。
他使用一份项目记忆文件记录不可妥协的规则，并按关注点分组。其中包括：
- 所有界面优先为手机设计，页面在移动网络环境下要在 2 秒内加载。
- 不存储银行卡号，用户可以一步删除账户和数据。
- AI 支出按日、按月、按客户限制，涉及真实费用的功能需要先获得创始人书面确认。
- 没有规格说明就不开发功能，需求变化时先改规格；“完成”以线上产品验证为准。
这套规则的核心是让文档而不是聊天成为事实来源。文章还提到，GitHub 的开源项目 Spec Kit 可以提供类似流程，将 constitution、specify、plan、tasks、implement 组织为 AI 工具中的命令。
第二道护栏：人工审查规格、自动检查和小 PR
在代码生成之前，每个任务先写一份从用户视角出发的规格说明。规格包含功能摘要、目标用户、用户故事、验收条件、边缘情况、明确不做的事项，以及待决策问题。作者认为，其中最重要的是“不做的事”和“待决策问题”：前者阻止 AI 自行发明需求，后者强制由人做出决定。
计划随后被拆成可以在几分钟内验证的小任务，每个有意义的变更都通过 Pull Request 和 CI 提交。作为非开发者，作者的审查清单并不依赖读懂每一行代码，而是看三件事：
- 变更是否符合规格说明。
- 自动检查是否通过。
- 以真实客户方式使用功能时是否正常。
小 PR 是这套审查能够成立的前提。它让变更范围更容易判断，也让每次变更具备可逆性。对于需要回滚策略的场景，素材给出的线索也来自这里：变更足够小，才更容易撤回。
第三道护栏：测试拦截和会话交接
当问题出现时，作者采用的流程是先要求 AI 列出原因，再讨论修复；随后把教训写成规则，放在对应功能的规格旁，让智能体在后续构建时读取。对于绝不能被破坏的规则，则进一步写成测试，由 CI 在构建阶段拦截。
他将这种方式概括为：英文规则在智能体读取时提供保护；测试则在智能体没有读取或遗漏上下文时也能提供保护。文章举的例子是：一个小 bug 反复运行并烧掉一天的 AI 预算，最终长期修复不是处理循环本身，而是给每次 AI 调用设置支出限制，并增加测试防止该限制被破坏。
文章还提供了几组提示词模板，用于降低会话失控概率：
- 在开发、修 bug 或接受新想法前，先要求 AI 给出理解和实施计划，并停止等待人工批准。
- 当长会话上下文过重时，要求 AI 生成可移交到新会话的完整提示，包括目标、需要读取的文件、已做决策、当前进度、下一步、分支和 Pull Request。
- 报告问题时，先写清操作、预期、实际结果和位置，再要求 AI 提出三个可能原因及验证方法。
- 将其他模型给出的评审意见交给 Claude，要求其逐条同意或反对，并依据规格和规则形成优先级计划。
对 AI 编程团队的意义
这组经验展示的是 AI 编程助手进入真实产品后需要的管理方式。开发者可以直接阅读 diff，但项目同样会遇到规则散落、上下文丢失、修复互相冲突的问题。文章给出的路径是把护栏前置：仓库中的规则文件约束边界，规格说明限制需求扩散，小 PR 和 CI 提供审查与回滚入口，测试把关键规则固化下来。
在早期阶段，作者的项目曾反复出现同类 bug；当记忆进入仓库后，后期重复问题减少，代码库每周变得更易修改。对于正在使用 Claude Code 或类似工具的团队，这套做法提供了一个可参考的判断框架：哪些决策必须人工确认，哪些规则应由测试强制执行，哪些变更必须保持可撤回。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ai-sheng-cheng-dai-ma-he-bing-1-156-ge-pr-hou-fei-kai-fa
