AI 辅助开发生产级项目：强模型与弱模型下的不同战法

这是一篇来自实践的经验总结。没有方法论的堆砌，只有在真实项目中反复验证过的做法，以及为什么这样做。

从“能用”到“用好”：AI 辅助开发的几个阶段

用 AI 写代码这件事，大多数人经历了差不多的路径：一开始觉得 AI 什么都能做，拿来就用；然后踩了几次坑，开始怀疑这玩意儿到底行不行；最后慢慢摸索出一套自己的用法，知道什么交给它、什么不能交给它。

我也是这样走过来的。经过多个项目的验证，我形成了一套相对稳定的工作流，适用于不同的模型能力和项目规模。这套经验的出发点很简单：人画圈，AI 在圈内跑。人的核心价值在于业务理解、边界把控和顶层设计——AI 写出来的代码在语法上可能没问题，但它不知道什么是你真正想要的、什么是系统不应该做的。AI 倾向于快速修改而不是最优架构，改烂代码的本领比人强，但也正因为如此，更不能让它在没有边界的情况下自由奔跑。人在回路中充当架构安全阀，确保核心逻辑可靠、边界不被侵蚀。随着模型能力的提升，这条边界在动态移动，但人的设计判断始终是它的锚点。

业界已经有了哪些共识

在总结自己的经验之前，有必要先看看业界在讨论什么。2026 年的社区讨论里，有几个被反复提到的观点正在形成共识。

CRTSE Prompt 框架是目前被引用最广泛的结构。它把一次 AI 交互拆成五个维度：Context（上下文）、Role（角色）、Task（任务）、Standards（标准）、Examples（示例）。我自己用下来体感非常一致——没有上下文的 Prompt，AI 给你的就是通用答案；给了足够的上下文，它才能给出可直接 merge 的代码。

AI 的优势区和危险区也已经基本形成共识。AI 最擅长的几件事：Boilerplate 生成、代码库探索、边界情况列举、测试用例补充。但它有三个公认的高危场景：安全相关的代码（它会自信地引入漏洞）、性能关键路径（它不了解你的数据规模和访问模式）、架构设计（它能生成结构，但无法生成可持续的边界划分）。这三件事永远需要人把关。

Austin Welsh 在一篇文章里说了一句话我觉得很准确：“Everyone can now ship code. Not everyone can ship systems that survive.” 翻译过来就是：打字谁都会，能活着上线的系统才是另一回事。这个判断在 2026 年仍然成立。

我的工作流：七个步骤的迭代循环

说了这么多背景，接下来是这套文章的核心——我在项目中实际使用的工作流。这套流程经过了多个项目的验证，从小型工具到中等规模应用都适用。

第一步：列粗规划

这一步完全由人主导。你不需要写得很详细，只需要把目标和约束说清楚：

• 要做什么，不做什么
• 技术栈偏好和限制
• 验收标准（最好是可以量化或测试的）
• 你知道的风险点

这一步的目的是给整个项目定调。AI 可以帮你补充细节，但它不能帮你做方向性的判断。

第二步：与 AI 对话，不断补充完善规划

把粗规划扔给 AI，让它提问题、补充风险点、给出候选方案。这个过程来回几轮，直到你对最终方案有信心。

关键点：方案确定之前，不要急着动手。规划阶段的每一分投入，都会成倍减少执行阶段的还债。

第三步：任务拆分与完整计划制定

由 AI 负责这一步，但人来做最终确认。我通常要求拆分到每个子任务足够小——理想情况下一个子任务在 1-2 小时内能完成。

每个子任务的结构是这样的：

## 任务 N: [标题]
- 目标：[一句话说清楚要完成什么]
- 验收标准：
  1. [可检查的具体标准]
  2. [可检查的具体标准]
- 依赖：[前置任务或必要的上下文]
- 风险：[已知的不确定的地方]

这种结构是我吃过亏之后才总结出来的。没有验收标准的任务，执行过程中一定会出现“我觉得完成了但其实没有”的拉扯。

第四步：审查任务并确认

在 AI 开始执行之前，我会 review 它的任务拆分。这个节点做一次整体校正，后续执行效率会高很多。

第五步：AI 按步骤执行，人做检查点

这是日常执行的核心循环。每个子任务完成后，我做一次检查：

• 测试是否通过
• 代码风格是否一致
• 有没有明显的逻辑问题
• 验收标准是否满足

这一轮检查不能省。AI 容易产生“语法对、逻辑错”的代码，看起来跑得通，实际有隐患。

第六步：提交代码，继续下一个任务

检查通过就提交，然后进入下一个子任务。没什么好说的，持续推进。

第七步：插入维护任务

这是很多人忽略但非常重要的环节。AI 在快速产出代码的过程中，不可避免地会积累技术债务：命名不一致、抽象不合理、有重复逻辑等等。如果不主动清理，债务会持续累积直到失控。

我的做法是：每完成 2-3 个功能子任务，插入一次维护任务，专门审视已完成的代码。

维护任务通常包括：是否有重复逻辑可以合并、命名是否保持一致、是否有明显的性能隐患、之前的抽象是否开始变得合理。

大型项目的中场维护

整个工作流循环往复，直到所有任务完成。对于大型项目，中途的维护节点比什么都重要。

强模型与弱模型：不是同一个战法

上面这套工作流在不同模型能力下的执行方式有本质差异。先说明前提：我的实战经验主要集中在强模型场景（GPT 5.5、GLM 5.1、Claude 3.7 这个级别），弱模型（GLM-4.7 级别）下的开发模式是基于能力差异的分析推演，而非直接的生产项目验证。

强模型：一次闭环，过程少干预

当前最强的模型已经有了显著的长程任务执行能力。做好前置计划之后，它们可以自主完成开发、检视、修改、测试验证、提交代码的完整闭环，中途长时间不需要干预。

强模型的核心优势在于：长程上下文保持——能在几百次交互中保持对全局目标的理解；以及连续执行能力——一旦计划确定，它可以在相当长的时间里自主推进，不需要你反复确认每个细节。

对于中小型项目，强模型配合好的规划，可以实现接近“说一句话，等结果”的体验。

弱模型：如果用，要怎么打

GLM-4.7 这个级别的模型，核心限制可能在于规划与拆分的质量、单步任务的粒度把控、以及跨 session 的上下文一致性管理。如果要在弱模型下做生产级开发，基于这些能力差异，可能需要考虑几个调整方向——以下为分析推演，尚未在实际项目中验证，不一定完全准确：

任务拆分可能需要人主导。 弱模型的全局规划能力可能不足以支撑自主拆分，让人先做粗拆、AI 负责细化、再由人确认拍板，可能是一种可行的分工方式。

每个 session 可能需要重新注入上下文。 弱模型的一致性管理能力如果有限，可以考虑在每个 session 开头用固定格式注入上下文：

当前任务：任务 3/5 - 实现用户认证 API
已完成：任务1(数据模型), 任务2a(路由定义), 任务2b(参数校验)
本 session 目标：完成任务3的核心实现
验收标准：1. JWT 签发正确 2. refresh token 逻辑完整 3. 错误返回符合规范

每轮可能只适合做一件事。 如果弱模型难以自主完成 plan→execute→check→fix 的循环，可以考虑每轮只做一件事、人做检查点、确认无误再推进下一步。听起来慢，但可能比让模型自行循环然后反复还债更高效。

中途维护任务可能更需要主动介入。 弱模型代码产出如果更容易出现风格漂移，中途清理技术债务的必要性可能更高。

弱模型场景的一种可能的循环结构：

┌─────────────────────────────────────────┐
│  人主导：粗规划 + 任务拆分（输出 SPEC.md）  │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│  Session 1：任务1（+ 上下文注入）         │
│  人确认结果 → 下一任务                    │
├─────────────────────────────────────────┤
│  Session 2：任务2（+ 上下文注入）         │
│  人确认结果 → 下一任务                    │
├─────────────────────────────────────────┤
│  Session 3：任务3（+ 上下文注入）         │
│  人确认结果 → 插入维护? → 下一任务         │
├─────────────────────────────────────────┤
│  ... 持续循环直到所有任务完成              │
└─────────────────────────────────────────┘

核心逻辑是：人的介入更及时，用人的判断力弥补模型推理能力的不足。但这些判断基于能力分析而非实战验证，实际效果有待检验。

约束放在哪里：项目规范的有效落地方式

如果你在公司项目里使用 AI 辅助开发，规范怎么落地是个实际问题。

很多人习惯把规范放在 Prompt 里，每次交互都要粘贴一遍。这不是不行，但有两个问题：一是容易遗漏，二是模型对粘贴进来的规范注意力分配不稳定。

更好的方式是利用工具本身的机制。很多现代 AI 编程工具（如 OpenCode）支持项目级的 AGENTS.md 文件。规范写入项目级 AGENTS.md，每个 session 开始时模型会自动加载，不需要每次粘贴。

项目级 AGENTS.md 建议包含以下内容：

技术栈约束——禁止什么、推荐什么。比如：禁止 any 类型、禁止 console.log 进入代码库、禁止原生 SQL 拼接、函数长度上限 50 行。

安全底线——所有 API 必须有权限校验、禁止在日志中打印用户敏感信息、数据库操作必须参数化查询。

提交流程——commit message 遵循 Conventional Commits 规范、合并前需要 review、PR 必须包含测试覆盖率报告。

代码风格——统一命名规范、错误返回格式、文件组织结构。

规范的内容本身不难写，难的是写完要真的被执行。AI 生成代码时会默认忽略你没有写进规范的东西。把规范显式写进 AGENTS.md，然后相信工具的机制，比每次靠 Prompt 提醒可靠得多。

写在最后

这篇文章总结的东西不是什么高深的方法论，都是在项目里反复踩坑、反复验证之后磨出来的经验。

核心只有三条：

人画圈，AI 在圈内跑。 边界在哪里，由人的业务理解、架构判断和设计决策来决定。AI 在给定边界内可以自由奔跑，越出边界则需要人拦截。

强模型已经可以实现长程自主执行，做好规划就能少干预。 弱模型则可能需要更及时的介入——但这一点尚未在实际项目中验证。

规范要落地，不要只存在脑子里。 项目级约束写进 AGENTS.md，团队共享，靠工具保证执行，比靠每次 Prompt 提醒稳定一百倍。

打字很便宜。思考才贵。