一、背景与趋势
自 2025 年末至今，Claude Opus 4.5/4.6、GPT-5.2/5.3-Codex、GPT-5.4、Gemini 3/3.1 Pro 等旗舰编程模型密集发布；几乎同一时期，Spec Kit、OpenSpec、Superpowers、everything-claude-code、GSD、gstack 等方法框架、工具包与流程化实践持续涌现并迅速扩散。AI 编程正明显进入高速演进、快速迭代的新阶段。
二、主流思路对比及 AI 编程本质分析
OpenAI 在 2026-02 发布的《Harness engineering》文章中披露，其团队已在五个月实验中，用 0 行手写代码构建并交付一个内部 beta 产品；Anthropic 则在 agent eval 文章中明确指出：所谓「agent」，本质上是模型与 harness 的联合系统，而不是单独的模型。这意味着，行业讨论的重心正在从「提示词怎么写」转向「让 agent 在真实环境里长期、稳定、可控地工作」。
同时，如果把最近半年最有代表性的项目放在一起看，会发现它们虽然名字不同，但其实都在试图回答同一组问题：任务如何表达，知识如何组织，模型何时该自由发挥、何时必须被约束，结果如何验证，人与 agent 的边界如何划定。
| 思路/项目 | 公开期 | 核心锚点 | 更擅长解决的问题 | 潜在弱点 | 更适合的团队阶段 |
|---|---|---|---|---|---|
| Spec Kit | 2025-09 | Spec 作为源头；先规格、后实施 | 把「需求—设计—任务拆解—实现」拉成结构化流程；减少 vibe coding 漂移 | 如果需求本身模糊，规格文档容易变成形式负担 | 需要把 AI 使用从「个人技巧」升级为「项目方法」的团队 |
| OpenSpec | 2026-01（1.0） | Spec 作为 source of truth | 强调 spec 锚定、工作流与产物一致性；更适合把「意图—规格—执行」绑定起来 | 对遗留项目、快节奏迭代项目，需要控制文档粒度 | 想把 AI 编程与正式产物挂钩的团队 |
| Superpowers | 2025-10 | skills + subagents + TDD 流 | 强调子代理协作、RED/GREEN TDD、逐任务 dispatch 与 review | 如果团队测试基础薄弱，容易只学到「花哨动作」而学不到底层约束 | 有一定工程纪律、希望提升中长任务执行能力的团队 |
| everything-claude-code | 2026 年初走红 | 大而全的 harness/skills 生态 | 把 skills、instincts、memory、security、research-first development 系统化打包 | 容易因为配置复杂、技能过多而带来学习和维护成本 | 探索广、愿意投入时间打磨个人/团队工作台的团队 |
| GSD | 2025-12 首发 | phase-based workflow + context rot 管理 | 强调 meta-prompting、上下文工程、阶段化执行、状态与计划文件 | 在小任务上可能显得偏重，且 token/time 成本敏感 | 希望把 AI 工作流工程化、流程化的团队 |
| gstack | 2026-03 | 角色化技能 + 浏览器/真实 QA 能力 | 把 CEO、设计、工程管理、发布、文档、QA 等技能角色化，并引入真实浏览器验证 | 强风格、强方法论，迁移到一般团队时需去个人化 | 希望快速获得「强意见流派」并借此重塑工作方式的团队 |
由此基本可以得出结论，AI 编程落地的关键不在于单纯追求模型能力，而在于解决以下四类核心问题：
- 信息：如何将团队已有知识、规则和约束清晰且简洁地提供给 AI
- 目标与计划：如何将任务目标、范围、边界和验收要求表达清楚，使 AI 能够准确理解任务
- 验证：如何让 AI 输出经过检查、验证和复核，确保结果可信、可交付
- 体系化治理：如何将 AI 的使用纳入团队统一流程和规范（流程、模板、质量管理、技术治理、过程可视化可观测、正向循环反馈）
因此，AI 编程落地的本质，不是「使用一个更强的模型」即可达成，而是要围绕「输入、知识、验证、流程」四个方面建立起稳定机制。只有当信息输入足够充分、任务表达足够标准、知识规则能够复用、质量验证能够闭环、使用过程能够纳管时，AI 才能从个人辅助工具，逐步转化为团队级生产能力。
由此可以看来，未来的主战场仍然是软件工程，差别是变成了「面向 AI 的软件工程」。
Agent 的最小闭环确实很简单，但生产环境里的失败，通常并不是因为 loop 写不出来，而是因为下面这些工程问题没有被系统解决：
| 常见失控点 | 本质上属于什么问题 |
|---|---|
| 上下文越来越脏，历史信息无法裁剪 | 上下文工程 / 状态管理 |
| 文档与规则越积越多，但模型吃不动 | 知识组织 / Progressive Disclosure |
| 工具越来越多，但权限没有分层 | 工具治理 / 安全边界 |
| 长任务没有 checkpoint，中断后无法恢复 | 任务状态机 / 持久化 |
| 错误没有分类，失败后只能整体重来 | 异常处理 / 重试与升级机制 |
| 结果「看起来像对了」，但没有客观证据 | 验证闭环 / Evals / 人工复核 |
| 人和 Agent 的职责边界模糊 | 组织设计 / 责任划分 |
未来几年真正稀缺的，不是「会不会调模型」，而是「能不能把 Agent 所处的环境做干净、做成体系、做出可重复验证的闭环」。模型能力决定上限，但软件工程决定稳定性、成本结构与可控性（面向 AI）。
三、另一种思路：Trust The Model
Anthropic 的 Claude Code 团队明确表示，他们的设计哲学是「模型之上尽可能薄的包装层」——模型能力才是核心，Harness 越轻越好。OpenAI 的研究员 Noam Brown 说过，为较弱模型构建的复杂脚手架，会被更强的模型替代。
Harness engineering 与 Trust The Model，不是二选一，而是：模型能力持续上移，工程控制持续下沉。
也就是说，越通用、越高频、越接近「常识」的部分，越会被模型和平台原生能力吸收；越是项目特有、组织特有、责任特有的部分，越需要被显式建设成 harness、流程、规则和验证机制。
四、哪些内容会变成 AI 的基本能力
未来 2-3 年，下面这类内容大概率会越来越多地被模型和平台原生能力吸收，不宜在这些高度通用的层面投入过重建设：
- 通用编码能力：主流语言、主流框架、常见 CRUD、基础重构、基础单测补齐
- 通用工程规范：命名、格式化、基础分层、常见目录结构、一般性提交约定
- 常见评审点：空指针、明显异常漏处理、重复代码、显而易见的安全与性能问题
- 为弱模型临时拼装的大量技巧性 scaffold：如果本质只是「补模型短板」，生命周期通常不会太长
OpenAI、Anthropic、Google 在 2025-2026 的旗舰编程模型路线，其实都在强化同一个方向：更长上下文、更强工具调用、更强复杂多步任务、更接近真实专业工作。这意味着，企业不应把大量精力放在重复教模型「行业常识」上，而应把力气放到真正有差异的约束与知识上。
五、哪些内容不会被 AI 替代，更值得建设
与上面相对，真正值得长期投入的，是那些「不通用、强约束、强责任、强组织属性」的部分。
| 建设对象 | 为什么不会自然被模型吞掉 | 建议沉淀方式 |
|---|---|---|
| 项目背景、目标、边界 | 这是「局部真理」，高度依赖团队、产品、历史债务与业务目标 | 项目级/模块级 AGENTS.md、docs、ADR、约束说明 |
| 质量门禁与验证闭环 | 模型再强，也不等于生成结果天然可交付 | 编译、测试、review、verify、回归、门禁 |
| 工具权限与安全边界 | 风险来自「AI 能做什么」，而不仅是「AI 会说什么」 | 权限分级、沙箱、审批、留痕、隔离 |
| 长任务状态与恢复 | 超长上下文不是万能解法，长任务必须越来越像状态机 | task / plan / verify、状态文件、checkpoint |
| 组织责任与人机协作边界 | 责任归属、风险承担、最终拍板权永远属于组织而不属于模型 | 高风险事项清单、人工确认点、审批规则 |
六、面向 AI 的软件工程，真正要建设什么
「面向 AI 的软件工程」适合拆成八类建设对象。它们既是技术问题，也是组织问题。
| 建设对象 | 核心问题 | 最低可行做法 | 成熟形态 |
|---|---|---|---|
| 任务表达 | 怎么把模糊意图转成 AI 可执行对象？ | 统一 task 模板 | 任务模板 + 规格模板 + 验收模板 |
| 上下文组织 | 怎么让 AI 拿到正确而不过量的信息？ | 项目级 AGENTS + docs | 索引化知识地图 + 按需加载 |
| 工具暴露与治理 | 给哪些工具、给多大权限？ | 只读/可写/高危分级 | 权限、审批、审计一体化 |
| 状态保存、恢复、裁剪 | 长任务如何不中断、不失忆？ | task/plan/verify 三件套 | 状态机 + checkpoint + 摘要裁剪 |
| 反馈回流 | 系统怎样把日志、错误、结果反馈给 AI？ | 统一日志与验证输出 | 结构化可观测性 + 可消费反馈 |
| 错误分类与升级 | 失败后怎么重试、补上下文、切人工？ | 按错误类型记录 | 标准化异常处理与升级策略 |
| 安全边界 | 哪些数据/操作不能直接交给 AI？ | 红线清单 + 人工确认 | 最小权限、隔离、留痕、追责 |
| 验证与结果证明 | 怎么证明「真的做对了」？ | 编译 + 测试 + 人工复核 | 自动验证链路 + 结果证据化 |
七、对研发团队和管理者意味着什么
1. 对研发人员的影响
未来被削弱价值的，不是「会不会写代码」这一能力本身，而是单纯依赖手工重复执行、缺少抽象和组织能力的工作方式。
更有价值的能力会逐步转向：
- 将模糊问题拆成清晰任务
- 将隐性知识显式化
- 将经验沉淀为模板、规则和案例
- 借助 AI 快速实现与验证
- 在复杂边界处做判断与把关
也就是说，未来比拼的将不只是编码速度，而是任务组织能力、知识组织能力、验证能力和协作能力。
2. 对研发管理者的影响
管理对象会发生变化。
过去主要管理「人怎么做事」；未来要同时管理：
- 人如何与 AI 协作
- 任务如何表达给 AI
- 规则如何沉淀给 AI
- AI 的使用过程如何纳入流程
- AI 产出如何验证与复盘
- 哪些动作可以交给 AI，哪些必须保留人工责任
因此，研发管理者未来不仅是项目推进者，也会越来越多地承担「AI 协作系统设计者」的角色。而这些，需要咱们管理者「再次」深入一线。
3. 对团队能力结构的影响
未来更具竞争力的，不一定只是某个单点技术最强的人，而是能够在以下几个方面形成复合能力的人：
- 理解业务目标
- 抽象问题与拆解任务
- 组织上下文与规则
- 驾驭 AI 高效执行
- 建立验证闭环
- 在效率、质量、安全之间做平衡
重复执行型能力会持续贬值，而能够组织 AI、约束 AI、放大 AI 价值的人，会越来越重要。
八、对部门的现实启示
回到部门当前阶段，最务实的做法不是直接追求「大而全」或「全面自动化」，而是先把最小可运行骨架搭起来：
- 先统一任务输入：把需求开发、BUG 修复、代码分析、测试用例生成等高频任务变成结构化输入
- 先建立最小知识骨架：项目级 AGENTS.md、必要的模块级 AGENTS.md、docs、skills、案例库
- 先打通最小验证闭环：编译、测试、人工复核、verify 记录
- 先高频低风险试点：阅读代码、小功能改造、低风险缺陷修复、测试补齐、页面转换
- 先做边界与红线：敏感数据、生产数据、账号口令、密钥、合同报价、未发布规划等一律纳入严格控制
这与咱们第一阶段试点文件的方向是一致的：不是一步到位，不是直接上复杂平台，也不是一次性写满所有规范，而是先形成统一方法、统一沉淀与最小验证闭环。
