我对 AI 软件研发平台的几个判断

很多人一说 AI 软件研发平台，第一反应还是：

• 一个聊天框
• 一个代码补全
• 一个能自动改文件的 agent

这些当然重要，但如果只停在这里，我觉得离“平台”还差得很远。

因为真正的软件研发，不是“生成一段代码”就结束了，而是要持续处理这些事情：

• 理解项目和相关项目的上下文
• 找到真实 contract 和事实源
• 在多步骤流程里推进任务
• 验证行为是否正确
• 在本地快速迭代
• 在正式环境稳定交付

所以如果要说我对 AI 软件研发平台的一个总体判断，那就是：

它不是一个更聪明的代码生成器，而是一个围绕软件研发全过程重新组织上下文、能力和验证的系统。

一、平台要解决的，不只是“写代码”

如果只把 AI 软件研发平台理解成“帮工程师更快写代码”，这个定义其实太窄了。

因为研发里的真正难点，很多时候根本不在“敲代码”本身，而在于：

• 需求和契约是否清楚
• 前后端和上下游是否对齐
• 哪些地方需要重点审核
• 哪些测试必须补
• 哪些改动会影响别的仓库或别的模块
• 哪些步骤应该先做，哪些应该后做

也就是说，平台真正要处理的是研发工作流，而不是单点代码动作。

所以一个更像样的 AI 软件研发平台，至少应该覆盖这些事情：

• 上下文管理
• 任务拆分和编排
• 代码与文档事实源定位
• 契约和测试校验
• review 和验收
• 本地开发与部署分层

如果这些都没有，只是把模型接进编辑器，那更像一个 AI coding tool，而不是研发平台。

这里还有一个我很看重的衡量标准：

平台必须真正提高研发迭代速度。

如果一个平台只是让演示看起来更智能，却让真实研发里的安装、验证、联调、review 和排错都变慢，那它就没有真正解决工程问题。

二、工程师依然重要，而且在很多平台里本来就是领域专家

很多人会下意识觉得，AI 时代的平台会削弱工程师的重要性。

我不这么看。

恰恰相反，在很多系统里，工程师依然是最关键的角色。

因为有很多平台型系统，它们的领域知识本身就是工程知识、开发知识和算法知识。

例如：

• 软件研发平台
• 运维部署平台
• 计算平台

这些系统的核心问题，本来就不是脱离技术实现的“业务常识”，而是：

• 开发流程如何组织
• 依赖关系如何管理
• 部署链路如何稳定
• 资源调度如何设计
• 哪些架构边界不能破
• 哪些算法和数据结构选择会直接影响系统能力

所以在这些平台里，领域专家很多时候本来就是工程师。

这也是为什么我不认同“有了 AI，以后只要会提需求就行”这种说法。

因为很多关键判断仍然必须依赖真正的领域知识，例如：

• 什么结果算对
• 什么风险不能接受
• 哪些抓手必须重点审核
• 哪些事情可以先交给 AI 展开

更具体地说，人在 AI 软件研发里必须介入，不是因为 AI 不能做事，而是因为它经常在三个层面出现偏差。

第一是需求理解偏差。

它可能抓住了表面任务，但没有真正理解背后的产品目标、工程边界和优先级。最后产出的东西看起来在响应需求，实际上已经偏离了真正要解决的问题。

第二是执行偏差。

这类问题尤其危险，因为 AI 很可能会表示“已经完成”，但实际只是完成了其中一部分，或者绕过了关键验证，或者改了不该改的地方。如果没有人和程序化验收介入，团队很容易在一个错误的完成状态上继续往前走。

第三是方案决策糟糕。

它有时会选择一个局部最省事、短期能跑通、但长期维护成本很高的方案。比如引入不必要的复杂度、破坏既有边界、选错抽象层级，或者为了快速通过当前任务牺牲后续一致性。

所以人的介入不是为了和 AI 抢执行工作，而是为了守住三件事：

• 需求是不是真的理解对了
• 执行是不是真的完成并通过验证了
• 方案是不是符合长期工程目标

说到底，AI 可以帮忙铺开执行，但平台能不能做对，仍然非常依赖工程师是否真的理解这个领域。

三、平台首先要做的是 context engineering

我越来越觉得，AI 软件研发平台的第一层能力，不是 prompt engineering，而是 context engineering。

因为 AI 在研发里最容易犯的错之一，不是“不会写代码”，而是：

站在错误的背景上做局部正确的事。

例如它可能：

• 不知道当前仓库直接依赖哪个后端项目
• 不知道 SDK 应该以哪个协议仓库为准
• 不知道某个页面改动还要联动检查哪个服务
• 不知道这个 repo 里的哪份文档才是过时说明，哪份才是事实源

所以平台必须让 AI 稳定拿到两类上下文。

第一类：稳定上下文

这类上下文会贯穿整个项目周期，适合沉淀到像 AGENTS.md 这样的地方，例如：

• 项目目标
• 关键目录和入口
• 直接依赖的相关项目
• 相关项目的路径或定位方式
• 常见联动检查点
• 本地开发和验证方式

第二类：动态上下文

这类上下文是协作过程中不断变化的，例如：

• 最近谁改了什么
• 哪些测试刚补上
• 哪个 contract 刚变了
• 哪个 agent 刚改了哪些文件

这里一个非常实用的点是：

如果 agent 之间能快速看到彼此的最新 diff，很多协作质量会直接提高。

因为这样大家不只是知道“项目长期是什么样”，还知道“项目刚刚发生了什么变化”。

所以如果平台不能稳定提供上下文，它就很难真的支持研发，只能支持一轮一轮临场对话。

另外，文档本身也应该成为上下文工程的一部分。

但这里我不看重“文档多不多”，我更看重：

文档是否高可读。

因为如果文档结构混乱、事实源不清、读起来很费劲，那么它对 AI 和对人都会同时失去价值。

高可读性的文档至少应该做到：

• 符合人的认知和阅读习惯
• 主题集中
• 结构清楚
• 范围受控，减少核对负担
• 事实源明确
• 行为和实现不混写
• 能快速把读者带到真实代码、schema、测试和 contract

这样文档才不只是说明材料，而是真正可消费的研发上下文。

这里还要特别强调一点：

传统的产品设计文档依然非常重要。

AI 软件研发平台不应该因为有了 agent，就把产品设计文档、需求拆分和进度追踪弱化掉。

但我不觉得平台必须默认套一层很重的 epic -> feature -> story 结构。

我更看重的是：

• 文档拆分是否符合人的认知习惯
• 每份文档的范围是否足够清楚
• 一次核对时需要同时对照的对象是否足够少
• 每个任务项是否都能直接对应实现、测试和验收结果

如果一个任务项本身已经是稳定、可核对、可验收的范围，那就没必要为了形式再额外拆出多层壳。

因为层级越多，人和 AI 在阅读、核对和追踪时的切换成本也越高。

平台真正应该减少的，不是文档数量本身，而是：

• 一次需要同时核对多少份文档
• 一个结论需要跨几层目录和几层抽象才能确认
• 一个变更需要追踪多少处平行描述

如果这些事情做不好，团队和 AI 很容易只围绕当前对话推进：

• 今天做了什么，靠人记
• 哪个任务项还缺实现，靠人记
• 哪个任务项已经开发但没验收，靠人记
• 哪些需求已经变更但实现还没跟上，还是靠人记

这对真实研发很危险。

因为人脑不应该承担完整项目状态机。平台应该把这些状态显式记录下来，让人、AI 和 CI / CD 都能围绕同一套进度结构工作。

所以我理想中的 AI 软件研发平台，不只是能帮忙写代码，还应该能把产品设计文档、任务拆分、实现状态、测试结果和验收状态串起来。

也就是说：

产品文档不是 AI 之前的旧工具，而是 AI 研发平台里的项目状态骨架。

进一步说，平台最好明确说明自己支持哪些核心文档类型。

至少我会要求它能稳定支持这几类文档：

• 用例文档：描述用户场景、目标、约束、主路径、异常路径和验收预期
• public API 文档：描述对外接口、输入输出、错误语义、版本边界和典型调用示例
• 技术实现方案设计文档：描述模块拆分、职责边界、关键数据结构、trade-off、落地步骤和风险点

这几类文档不能混成一团。

因为它们分别回答的是不同问题：

• 用例文档回答“系统要解决什么问题，用户怎么使用”
• public API 文档回答“系统对外暴露什么 contract，别人该怎么接”
• 技术实现方案设计文档回答“团队准备怎么实现，为什么这样实现”

平台如果不能把这几类文档区分清楚，人和 agent 就很容易在“需求、接口、实现”三层之间来回混线，最后既难 review，也难追踪变更影响。

这里还有一个容易被低估的点：

AI 加速了 coding 的速度，但并没有让软件开发周期消失。

很多任务确实可以更快完成初版实现，但真实研发仍然要经历：

• 需求澄清
• 方案选择
• 任务拆分
• 实现
• 联调
• 测试
• review
• 修复
• 验收
• 发布

这些环节不会因为代码生成更快就自动消失。

甚至在 AI 参与之后，进度管理会变得更重要。

因为 AI 可能很快铺开很多改动，但团队仍然需要知道：

• 哪些任务项只是生成了代码
• 哪些任务项已经通过测试
• 哪些任务项已经完成 review
• 哪些任务项还卡在验收
• 哪些任务项因为需求变更需要重新打开

如果没有清楚的进度管理，AI 加速的可能只是“产出改动”的速度，而不是“稳定交付”的速度。

所以平台不能只看 coding throughput，还要看整个开发周期里的状态流转是否清楚。

进度管理在 AI 时代不是过时的项目管理负担，而是让高速生成真正进入可控交付链路的必要结构。

再往前一步说，我会把“文档树本身是否逻辑清楚”也当成平台能力的一部分。

因为很多时候，问题不在单篇文档，而在整棵目录树从根上就分得不对。

我很看重一个原则：

每一个层级下的子目录和文件，都应该只沿一条单一的逻辑轴划分。

例如某一层如果已经决定按“系统模块”来分，那这一层下面就不应该同时混入：

• 按生命周期划分的目录
• 按角色划分的目录
• 按抽象层级划分的目录

反过来，如果某一层决定按“行为 / 实现”来分，那这一层下面的兄弟节点也都应该沿这条轴保持一致，而不是一部分在讲功能，一部分在讲组件，一部分又在讲排期。

因为一旦同一层目录同时混用多条逻辑轴，读者和 AI 都会遇到同一个问题：

• 不知道应该去哪里找某类信息
• 不知道兄弟目录之间是不是同一层对比关系
• 不知道某份文档为什么在这里，而不是在别处

结果就是：

• 树看起来很大，但定位很慢
• 文档之间边界越来越模糊
• 相近内容开始重复堆积
• 后续新增内容只能继续往混乱结构上叠

所以我理想中的平台，不只是帮你生成文档，还应该帮助团队持续检查文档树是否还保持结构自洽。

也就是说，平台应该能帮助回答：

• 当前这一层目录是沿哪条逻辑轴在分
• 下面这些子节点有没有混入别的分类标准
• 某个主题是不是被放错层级了
• 两篇文档到底是互补关系，还是重复关系

如果连目录树本身都没有稳定结构，那后面再谈 SSOT、引用真实资产、inline 绑定测试和代码，都会变得很别扭。

这里还有一个我很看重的要求：

相关信息不能只是“能跳过去看”，而应该尽量被强绑定在一起。

例如一份文档如果在描述某个功能，那么人在读这段描述时，最好就能 inline 看到：

• 对应的验收测试在测什么
• 最近一次测试结果是什么
• 哪些 case 通过了，哪些 case 失败了

同样，如果一段内容在描述某个文件、某个数据结构或者某个 contract，那么读者最好也能 inline 看到：

• 相关代码片段
• 真实 schema 或类型定义
• 代表性的输入输出例子

因为如果文档、代码、测试和结果只是彼此链接，但阅读时必须不断跳转、自己拼接上下文，那么事实虽然“理论上可达”，但在实际协作里仍然是松散的。

而一旦这些信息能被强绑定、就地展示，很多判断都会快很多：

• 这段描述是不是已经过时
• 这个结构有没有真实实现
• 这条验收规则是不是已经落成测试
• 现在说的“通过”到底是文档结论，还是程序结果

所以我理想中的平台文档，不只是能引用事实源，而是要尽量让描述、代码、测试和结果在阅读点上发生汇合。

另外，平台还不能只是“把信息都放出来”，而应该能主动 highlight 真正关键的锚点。

因为真实研发材料一多，信息过载很快就会出现。

如果所有内容在视觉和结构上都一视同仁，那么人和 AI 都容易在大量细节里迷失，反而抓不住最该优先看的东西。

我会特别希望平台能把这几类内容长期高亮出来：

• 边界数据模型
• 设计文档
• 验收测试

原因很直接。

边界数据模型决定系统和外部世界怎么对接，很多接口问题、上下游联动问题，最后都会落到这里。

设计文档决定当前方案到底准备怎么做，很多实现分歧、职责边界和 trade-off，也都应该优先回到这里看。

验收测试决定什么才算真的做对了，它不只是附属材料，而是行为约束真正落地后的可执行表达。

所以我理想中的平台，不只是允许这些资产存在，而是要让它们在阅读、review、执行和验收过程中一直被显式突出。

这样工程师和 agent 才不会在大量普通说明、历史讨论和局部实现细节里，把真正关键的约束看丢。

四、平台必须把 contract 和 verification 放在核心位置

AI 最危险的地方，不是它完全不会做，而是它很容易生成“看起来差不多”的东西。

所以一个 AI 软件研发平台，如果没有把 contract 和 verification 放在核心位置，最终一定会漂。

这里我觉得至少要有几类基础能力：

• public API contract
• OpenAPI 或 schema
• 真实数据模型
• examples
• 测试用例
• 程序化质检

这里我会进一步把 examples/ 当成每个项目都应该有的约定目录。

它不是可有可无的演示材料，而应该是项目里的标准事实源之一。

这个目录里至少应该沉淀几类典型样例：

• 典型的 public API 用法
• 典型的输入数据
• 典型的输出数据

这样做有两个直接价值。

第一，文档在解释行为、接口和数据结构时，可以直接引用这些例子，而不是每篇文档各自手写一套容易漂移的示例。

第二，测试在做正例验证时，也可以直接复用这些样例，而不是文档一套例子、测试再复制一套相似但不完全一致的例子。

我很喜欢这种资产组织方式，因为它能让 example 同时服务两件事：

• 作为文档可直接引用的说明材料
• 作为测试可直接消费的正例样本

这样 example 就不再只是“帮助理解”的附属内容，而是连接文档、contract 和测试的一层共享资产。

很多自然语言文档在早期是必要的，但一旦有了真实资产，就应该明确让真实资产成为 SSOT。

例如：

• 数据模型优先引用真实模型代码
• JSON 结构优先引用 schema 或校验模型
• 验收规则优先引用测试用例
• 流程优先引用真实调用关系、路由关系或状态机结构

这里我很看重一个过程观：

文档不是一开始就不重要，而是在真实代码、schema、测试出现后，应该主动把早期文本替换成对真实资产的引用。

很多设计在最早期，还没有代码、schema、测试用例，甚至连接口都没真正落出来。

这时候用 markdown 把事情先说清楚，完全合理，而且往往是必要的。

例如早期可以先用文档描述：

• 数据结构草案
• 验收规则草案
• 状态流转
• 错误语义
• 示例输入输出

因为如果连这些都还没讲明白，就直接进入实现，后面只会更乱。

但问题在于，很多团队会把这些“早期说明”长期保留下来，最后变成和真实系统并行存在的第二套事实源。

一旦真实代码和测试已经出现，就应该开始做替换，而不是继续让自然语言描述和真实实现长期并存、互相漂移。

更具体地说，我会倾向于这样收口：

• 早期没有真实模型时，先用 markdown 描述数据结构
• 有了真实模型代码后，文档改成引用真实模型，而不是继续手写字段定义
• 早期没有验收资产时，先用 markdown 写验收规则
• 有了真实测试用例后，文档改成引用测试和测试组织方式，而不是继续手写一套平行验收标准

也就是说，文档在不同阶段承担的职责并不一样：

• 早期帮助团队对齐理解
• 中期帮助团队连接设计和实现
• 后期更多承担索引、导航和解释作用，把读者带到真实代码、schema、测试和 contract

如果到了后期，文档还在重复维护一整套已经被代码和测试表达过的事实，那它通常就不再是在帮助研发，而是在制造漂移。

这里还有一个平衡点：

流程不能太死板，但关键质控必须能在必要时收紧。

真实研发不可能从第一天就拥有完整的 contract、测试、验收资产和 review 结论。很多时候，早期探索阶段允许这些关键质控临时缺失是合理的，否则流程会把还没成型的想法提前卡死。

但“允许临时缺失”不等于“把缺失当成通过”。

平台应该把这些缺口显式记录下来，例如：

• 当前任务项还没有对应验收测试
• 当前接口还没有稳定 contract
• 当前方案还没有经过 review
• 当前变更只完成了初版实现，还没有进入独立验收

在探索、草案、局部验证阶段，这些状态可以存在；但一旦进入合并、发布、跨模块联动或关键用户路径，平台就应该自动收紧，把这些缺口变成必须处理的门禁。

也就是说，好的平台流程不是“一开始就全部硬卡”，而是能区分阶段：早期允许欠账，中期持续暴露欠账，后期在关键节点强制收口。

平台的责任，不只是“能生成”，而是要帮助团队持续把行为约束沉淀成可执行验证。

否则 AI 写得越快，偏差只会扩散得越快。

遇到 bug 时，这一点会变得更重要。

平台不能鼓励 AI 一看到报错就直接改代码。

更稳的处理顺序应该是：

• 先定位问题发生在哪里
• 再确认触发条件是什么
• 尽量用测试用例、最小复现或可重复脚本把问题复现出来
• 看到失败结果后，再针对性修改
• 修改后重新运行同一个复现用例，确认 bug 被修掉

也就是说，bug 修复不应该是“根据错误描述猜一个改法”，而应该是先把问题变成可复现事实，再用验证闭环收口。

如果没有复现，AI 很容易改到看起来相关、实际上不相关的地方。

如果没有定位，AI 很容易做大范围搜索式修改，把一个局部 bug 变成一串新的不确定性。

所以平台应该把“复现 -> 定位 -> 修改 -> 回归验证”变成默认流程，而不是把“快速改一版看看”当成默认流程。

这里还有一个原则我会放得很前：

能用传统程序解决的，就不要依赖 AI。

因为很多研发问题，本来就更适合交给确定性程序处理，例如：

• 结构化校验
• 批量一致性检查
• 链接和引用关系扫描
• schema 验证
• 测试执行
• 固定规则下的代码生成和转换

如果这些事情已经可以被传统程序稳定完成，却还强行交给 AI，自然会带来更慢、更贵、更不稳定的链路。

所以一个成熟的平台，不是“凡事先上 AI”，而应该优先判断：

• 能否直接用传统程序解决
• 如果不能，再看是否适合 AI 写程序来解决
• 只有前两者都不合适，再考虑 agent 自主能力

这不是反对 AI，而是把 AI 放到真正需要它的地方。

五、本地开发和正式部署，必须分开设计

一个常见误区是，把 AI 研发平台理解成“统一一切环境”。

但从工程角度看，本地开发和正式部署其实有不同目标。

本地开发最重要的是：

• 快速迭代
• 快速验证
• 不要被重型流程拖慢

正式部署最重要的是：

• 稳定
• 可复现
• 可审计
• 可回滚

如果平台不能区分这两层目标，就很容易出现两种坏结果：

• 本地开发被部署级约束拖慢
• 正式部署又继承了开发期的临时做法

所以我会很看重平台有没有支持这些能力：

• 本地化安装
• 本地缓存和轻量依赖管理
• 本地快速验证闭环
• 独立的部署级构建和发布链路

这里我还会特别看重：

本地模式和生产模式下，依赖管理方案应该明确分开。

因为很多平台型项目都会依赖一组自己维护的库、协议仓库或者相关项目。

如果本地开发和远程部署还沿用同一套依赖安装方式，通常会同时损失两边的好处：

• 本地改动一个依赖库，验证链路很慢
• 生产环境又缺乏稳定的版本锁定和可复现性

所以我更倾向于平台直接支持这种分层策略：

• 本地开发时，允许可编辑安装，方便联动修改和快速验证
• 远程环境或生产模式下，锁定明确版本，保证可复现和可审计

这样做非常符合两边的真实目标。

本地开发需要的是：

• 改完依赖后立即联动验证
• 不用每次都走完整发布流程
• 多个相关项目能像一个工作区一样快速协作

正式环境需要的是：

• 依赖版本明确
• 构建结果稳定
• 问题可追溯
• 回滚有抓手

如果一个平台不能把这两套依赖策略都支持好，那么本地会被版本流程拖慢，生产又会被开发期的松散依赖污染。

所以在我看来，这不只是包管理细节，而是平台是否真的理解“本地迭代”和“正式交付”是两种不同工程目标的体现。

AI 可以加速代码修改，但如果本地验证一轮要等很久，整个研发效率还是上不去。

所以对平台来说，迭代速度不是体验优化项，而是核心能力。

如果一轮“改动 -> 验证 -> 收口”的闭环不够快，AI 再强也只能更快地产生等待。

六、平台应该内置“约定优于灵活”的工程骨架

我不觉得 AI 软件研发平台应该把所有工程组织问题都做成高自由度配置题。

很多事情其实没必要追求过度灵活，例如：

• 目录结构怎么组织
• Git 流程怎么走
• 开发语言怎么选
• 开发框架和基础库怎么选
• CI / CD 怎么分层
• 哪些检查在本地跑，哪些检查在合并前跑
• 哪些分支策略和门禁是默认要求

如果这些东西每个项目、每个团队、每次启动都重新设计，表面上看很灵活，实际上只会带来：

• AI 更难学会稳定工作方式
• 人与人之间协作成本更高
• 不同仓库之间迁移和复用变慢
• 很多低价值的流程争论反复出现

这里我其实有一个越来越强的判断：

平台不应该把这些工程选型题继续甩给用户，也不应该默认交给 AI 临场发挥。

因为这些选择看起来像“偏好”，实际上常常非常依赖长期经验积累。

例如：

• 什么时候 Git 流程该偏 trunk-based，什么时候该保留更强的 review 分支约束
• 某类系统更适合 Python、TypeScript、Go 还是别的语言
• Web 框架、任务编排框架、数据校验库和测试库该怎么搭配
• CI 应该做到多细，CD 应该做到多自动
• 哪些库虽然流行，但并不适合长期维护和 agent 稳定协作

这些判断背后，牵涉的都不是单点语法喜好，而是：

• 生态成熟度
• 调试和排错成本
• agent 是否容易稳定使用
• 团队招聘和协作成本
• 本地开发速度
• 正式环境的稳定性和可审计性

说得更直接一点，这类判断往往要靠很多年真实踩坑，才会慢慢形成稳定标准。

我自己花了十多年，才逐步建立起对这些工程决策的理解和判断力。到现在为止，我也不觉得现阶段的 AI 已经能够在这些问题上长期、稳定、始终做出妥善决策。

更现实一点说，在日常协作里，我几乎每天都要花很多次精力去纠正 AI 的错误理解和不合适的决策。

而且这些问题很多并不是“模型完全不会”，而是更麻烦的那一种：

• 它好像理解了一部分，但关键边界理解错了
• 它给出了一个能运行的方案，但从长期维护看并不合适
• 它局部上说得通，但放到完整工程链路里会产生新的不一致

这也是为什么我越来越不接受一种想法：

既然 AI 看起来已经能做很多事，那工程上的关键选择也可以顺手交给它。

因为真实感受恰恰相反。你不是偶尔纠正一次就够了，而是要持续、反复、每天纠正很多次。

它有时可以给出不错建议，但还远远没有可靠到可以让平台把这类预决策工作完全交给它。否则很容易出现：

• 同一个平台里的不同项目选型风格越来越散
• 同类问题在不同仓库里反复得到不一致答案
• AI 今天推荐一种做法，明天又推荐另一种做法
• 用户自己其实没有足够经验判断，只能被动接受表面上说得通的建议

所以在我看来，平台真正该做的不是“提供无限选择”，而是：

把高频、关键、容易产生长期影响的工程决策先收口成默认最佳实践。

所以我更偏向一种思路：

平台应该内置一套足够稳的最佳实践默认值，而不是默认把工程治理交给每个团队从零发明。

例如平台完全可以预置：

• 一套清楚的目录组织约定
• 一套可审阅的 Git 分支和合并策略
• 一组默认开发语言和适用边界，而不是让每个项目先从语言大战开始
• 一组默认框架、基础库、测试库和目录组织组合
• 一套分层的 CI / CD 模板
• 一套默认的质量门禁
• 一套适合 agent 执行的本地验证闭环

更进一步说，我理想中的平台最好做到：

• 默认技术栈已经选好
• 默认 Git 流程已经选好
• 默认测试框架已经选好
• 默认 CI / CD 路径已经选好
• 默认本地开发和生产部署分层方式已经选好

用户当然可以在有充分理由时改，但不应该一上来就先面对一大堆开放选择题。

因为多数用户真正想解决的是业务和产品问题，不是先花很多时间学习：

• 哪种 Git 流程适合自己
• 哪门语言长期更稳
• 哪个框架未来更容易维护
• 哪组库组合对 agent 更友好
• CI / CD 到底该怎么分层才合理

这些内容如果都让用户自己想、自己学、自己试，平台就没有真正替用户承担复杂度。

而如果把它们继续交给 AI 现做决定，问题也不会消失，只是会变成另一种更隐蔽的不稳定：

• 决策理由不透明
• 不同项目之间不可比
• 后续维护者难以理解为什么当初这么选
• agent 在不同仓库里很难形成稳定操作习惯

所以我越来越认同一种平台观：

真正好的 AI 软件研发平台，不是把所有选择都暴露出来，而是主动把大量正确选择预先做掉。

平台先把默认路径铺好，用户和 AI 再沿着这条路径高效执行。这样才能减少错误决策、减少风格漂移，也减少人和 agent 之间反复对齐的成本。

例如在目录约定上，我就很希望平台默认要求每个项目都带一个 examples/：

• 放典型的 public API 用法
• 放典型的输入数据
• 放典型的输出数据

这样 AI、文档和测试都会更容易围绕同一组例子工作，而不是在不同位置各写各的“示意样例”。

除了目录、Git 和 CI / CD，我还会希望平台把一些常见横切面直接内置处理。

因为这些东西虽然不是业务主逻辑，但几乎每个项目都会反复遇到。

例如：

• 用户交互后内部出错时，警告应该怎么显示
• 顶部通知应该怎么弹出、收起和分级
• 成功、失败、部分成功的反馈语义怎么统一
• 异常信息是给用户看、给工程师看，还是分别展示

如果这类问题每个项目都自己重新定义一遍，最后通常只会得到很多风格不一致、行为不一致、可维护性也不一致的实现。

所以我更倾向于平台直接给出默认方案。

例如：

• 一套统一的 warning / error 展示方式
• 一套统一的顶部通知机制
• 一套统一的反馈分级和默认文案策略
• 一套统一的日志、错误码和用户提示衔接方式

这样团队在做新项目或新模块时，就不用反复讨论这些横切面该怎么处理，而是默认站在一套已经验证过的最佳实践上往前做。

这类能力看起来不“炫”，但它们非常影响真实产出效率。

因为平台真正该内置的，不只是最核心的主流程能力，也包括这些高频、重复、容易做散的公共处理。

这里的重点不是“一刀切”，而是：

先把高频场景做成约定，再允许少量有理由的例外。

因为大多数团队真正需要的，并不是无穷多种流程组合方式，而是一条已经被验证过、可以高效产出的默认路径。

比如目录结构，如果平台已经有稳定约定，那么 AI 就更容易知道：

• 测试通常应该放哪里
• contract 通常应该放哪里
• 文档和真实代码之间应该怎么互相引用

比如 Git 流程，如果平台已经内置默认约束，那么 AI 和人都更容易形成一致预期：

• 什么时候该开分支
• 什么时候该补测试
• 什么时候该发起 review
• 什么时候允许合并

再比如 CI / CD，如果平台已经把本地验证、PR 门禁、主干发布这些层次分清楚，那么很多原本靠经验记忆的事情就能被平台直接托住。

我还会进一步要求：

常见工程场景应该由平台直接提供统一能力支持，而不是让每个项目自己写一堆脚本。

因为很多项目反复写脚本，其实并不是在沉淀差异化能力，而是在重复实现同一批高频工程动作。

例如这些事情，本来就非常适合平台内置：

• commit
• push
• pr
• main sync
• 分支或临时产物的 delete
• CI / CD
• 本地可编辑安装依赖库
• skill 安装
• 环境安装
• 锁版本

如果这些基础动作都散落在各项目自己的脚本里，通常会出现几个问题：

• 用法不一致
• 质量门禁不一致
• 参数约定不一致
• agent 很难稳定复用
• 仓库一多之后维护成本越来越高

更合理的方式通常是：

• 平台提供统一入口
• 平台提供默认约束
• 项目只补必要的少量特化

这样做之后，团队真正要维护的就不再是一堆脚本细节，而是：

• 哪些步骤是默认流程
• 哪些场景允许例外
• 哪些地方需要项目级扩展

这会让工程治理清楚很多。

因为脚本越分散，经验越难沉淀；入口越统一，最佳实践越容易真的被执行。

这样做的价值非常直接：

• 降低项目启动成本
• 降低 agent 学习成本
• 降低跨仓库协作成本
• 提高执行一致性
• 让最佳实践真正变成默认生产力，而不是散落在口头经验里

所以我会把这件事理解成：

平台不是提供“无限灵活的工程积木”，而是提供“少量但强约束、可高效产出的工程骨架”。

对大多数研发团队来说，后者通常更有价值。

七、传统 skill 不够，平台要支持可编排的能力模块

如果只看单点能力，skill 很有价值。

但真实研发任务通常不是一个技能独立完成的，而是多个能力串起来：

• 一个模块读上下文
• 一个模块分析 contract
• 一个模块修改代码
• 一个模块补测试
• 一个模块做 review 和验收

现实里，一个模块的输出往往就是另一个模块的输入。

所以平台不能只提供一组彼此独立的 skill，还要支持：

• 明确输入输出
• 动态参数注入
• 上下游衔接
• 串行与并行编排
• fail-fast 边界
• UI 和工作流承接

这里我还会特别区分两类 skill。

第一类是系统内置能力的封装，例如：

• 对某个 API 的调用封装
• 对某个 CLI 的命令封装
• 对某类平台资源的标准化读写

这类 skill 很重要，因为它们能把底层操作收口成稳定入口。

但如果平台只支持这类 skill，我觉得还是不够。

因为研发里还有大量高价值 skill，并不直接对应某个系统原子功能，而是在组织一套工作方法。

例如：

• 按一组规则 review 文档树
• 对 PR 做分层检查和收口
• 对设计稿、文档、代码和测试做一致性核对
• 按 worklist 循环执行并逐项验收
• 做复盘、质检和结构化纠偏

这些 skill 的价值，不在于“调了哪个 API”或者“跑了哪条 CLI”，而在于：

它们把复杂任务里的判断顺序、执行步骤、验收方式和收口逻辑固定了下来。

所以一个成熟的平台，不应该只提供“系统直接功能”的 skill 运行能力，也应该提供“非系统直接功能”的 skill 运行能力。

换句话说，平台既要能运行工具型 skill，也要能运行方法型 skill。

前者解决“怎么调用系统能力”。

后者解决“怎么把一类复杂工作稳定做对”。

很多时候，真正拉开平台差距的，恰恰是后者。

因为 API 和 CLI 的封装别人也能做，但那些可复用的 review 方法、验收流程、文档治理规则、跨步骤工作流，才更接近团队真正沉淀下来的生产经验。

这里还有一个很重要的点：

skill 必须支持持续迭代。

真实使用里，skill 很少能一次写对。它往往会在执行中暴露问题，例如：

• 某个触发条件描述不清
• 某个步骤顺序容易被误解
• 某个验收要求没有写成可执行检查
• 某个边界场景会让 agent 走错方向
• 某个规则只在当前上下文里成立，换个场景就失效

所以平台不应该把 skill 当成静态说明书，而应该把它当成会持续进化的工作流资产。

每次 agent 执行出错，都应该能反过来沉淀成 skill 的改进输入：

• 这次偏差是什么
• 偏差发生在哪个步骤
• 是指令不清、缺少约束，还是验收方式不够硬
• 应该补一条规则、补一个 fail-fast 检查，还是调整执行顺序
• 修正后的 skill 如何验证真的生效

这种反思不是额外流程，而是 skill 能不能越用越稳的关键。

更进一步，修正后的 skill 不能只在当前 thread 里测试。

因为当前 thread 已经包含了大量上下文：用户刚刚指出的问题、agent 刚刚做过的分析、当前对话里的临时提醒，以及模型短期记住的纠偏方向。此时即使 agent 表现正确，也很难判断到底是 skill 生效了，还是当前上下文在帮它兜底。

所以更可靠的验证方式是：

• 修改 skill 后，开启一个新的 thread
• 只给新 thread 必要的触发输入
• 观察 agent 是否会自动按修正后的 skill 行事
• 用同类任务或最小复现场景检查问题是否不再出现
• 如果新 thread 仍然犯同类错误，说明 skill 还没有真正修好

也就是说，skill 的验收应该尽量接近“冷启动测试”。

只有在新的 context 里仍然生效，才能说明修正真正进入了 skill 本身，而不是只依赖当前对话里的临时记忆。

这也是为什么我会更偏向 GEM 这种能力模块化思路。

因为研发平台真正需要的，不是“很多 skill”，而是：

很多能被系统稳定编排、消费和组合的能力模块。

八、平台必须支持长时间运行的批量任务

很多平台 demo 看起来很聪明，是因为它们擅长处理一次性、短链路的小任务。

但真实研发里，经常会出现另一类任务：

• 上百个文档逐份 review
• 按 N 条规则逐条自查
• 每轮修完再重新检查
• 连续跑 2 到 3 轮，直到基本查不出新问题

这种任务的复杂度，往往不是一次 prompt 能不能答对，而是：

能不能把一个很长的执行链条稳定跑完，并且确保每一步真的落实。

如果让我再把这类平台能力收得更明确一点，我会特别看它能不能稳定支持三件事：

• 计划任务能连续执行到底，而不是跑到一半就停在自然语言总结里
• 能反复自检，直到确认没有明显偏差和遗漏，而不是只做一轮表面检查
• 能把大批量对象显式展开后稳定执行，而不是把“批处理”退化成一次笼统请求

比如一个 100 x N x 2~3 轮的检查任务，如果没有平台级支撑，很容易在中间退化成：

• 口头上说“已经检查过了”
• 实际只检查了部分文档
• 某些规则只在前几份文档上执行了
• 第二轮和第三轮只是重复第一轮的结论
• 中途上下文窗口一变，之前的状态就丢了

所以我会把这类能力也看成平台底座，而不是高级增强项。

一个真正能支撑长时间运行的研发平台，至少要有这些东西：

• 持久化的 worklist，而不是只存在于对话上下文里
• 明确的任务展开结构，例如“文档 x 规则 x 轮次”
• 能按 plan / worklist 连续推进到收口的执行引擎，而不是每做一段就等人重新提醒
• 每一项执行后的结构化结果记录
• 可恢复、可续跑、可跳过、可重试的状态机
• 每轮执行后的独立验收，而不是只看 agent 自述
• 明确的批处理执行能力，例如分片、循环、重试、进度统计和失败项回收

这里有三个很现实的使用原则。

第一，计划不能只是写出来，还要能连续执行到底。

很多平台会把“生成一个 plan”当成任务编排，但真正困难的是后面这段：系统能不能按这个 plan 持续推进，不因为上下文切换、对话结束、单轮响应完成，就把整件事停在半路。也就是说，平台要支持的不是“列计划”，而是“沿计划执行到收口”。

第二，不要相信 AI 说“这个任务已经完成了”。

这个判断必须回到可检查的执行记录、diff、测试结果和验收项，而不是只看自然语言总结。尤其是复杂任务，AI 很可能完成了其中一部分，就把整体任务描述成已经收口。

第三，自查不能只跑一遍，而且目标应该是尽量查到没有明显偏差和遗漏。

对于复杂任务，平台应该支持重复几轮自查，直到查不出新的有效问题，或者触发人工判断。这里的关键是“独立复查”：第二轮和第三轮不能只是复述第一轮结论，而要重新按规则检查修复后的结果。

第四，不要把一大批对象笼统交给 AI，然后期待它自己稳定做完。

比如“把这 100 篇文档都按这 20 条规则检查一遍”这种任务，如果只是丢给 agent 自由发挥，大概率会漏。它可能漏掉部分对象，漏掉部分规则，或者在后半段把检查标准逐渐简化。

更好的方式是让平台先把批量任务显式展开，再逐项执行、逐项记录、逐轮复查。也就是说，不是让 AI 自己声称“我都看过了”，而是让系统能证明：

• 哪些对象被处理过
• 每个对象按哪些规则处理过
• 哪些问题已经修复
• 哪些修复进入了下一轮复查
• 为什么现在可以停止

这也是为什么我会把“批处理任务执行”单独当成平台要求，而不是普通 agent 能力的附属品。

因为真正的批处理不是“让 AI 同时做很多事”，而是让系统显式管理：

• 当前批次范围
• 分片和顺序
• 每项是否完成
• 失败项怎么回收
• 下一轮复查从哪里继续

这里尤其重要的一点是：

平台不能只记录‘跑过了’，而要记录‘对哪个对象、按哪条规则、在第几轮、产出了什么结果’。

否则所谓长时间运行，最后往往只是长时间输出自然语言，而不是长时间稳定执行。

我会很看重平台是否能把这类任务显式展开成类似这样的结构：

• 文档 A，规则 1，第一轮检查
• 文档 A，规则 2，第一轮检查
• 文档 B，规则 1，第一轮检查
• 文档 B，规则 2，第一轮检查
• 第一轮修复后，再进入第二轮独立复查

这样平台才能真正知道：

• 哪些项目已经完成
• 哪些项目失败了
• 哪些项目还没开始
• 哪些项目是复查通过
• 哪些项目只是“改过”，但还没被独立验收

如果没有这层显式执行结构，所谓“自迭代直到查不出问题”，通常就无法保证真的落实。

因为这里最难的，不是生成意见，而是保证：

• 每一份都被扫到
• 每一条规则都被执行
• 每一轮都是独立复查，而不是沿用旧判断
• 收敛条件清楚，不会无限空转

所以在这类长任务里，平台真正要提供的，不只是 agent autonomy，而是 execution reliability。

换句话说，平台不应该只让 agent “一直跑”，还应该让系统能回答这些问题：

• 现在总进度是多少
• 卡在哪一批对象
• 哪条规则最容易反复出问题
• 哪些修改已经进入下一轮复查
• 为什么系统判断现在可以停止

只有这些都能被追踪，长时间运行才不是一种主观感觉，而是一种可审核、可验证、可恢复的工程执行能力。

九、平台应该支持 UI 和 CLI 的双轨触发

我不认为 AI 软件研发平台应该只提供一种交互入口。

更合理的形态通常是：

• 一条轨是 UI 触发，方便人直接查看、选择、审核和操作
• 一条轨是 CLI 触发，方便脚本、skill 和 agent 直接调用

因为真实研发里，这两类场景都长期存在。

有些操作更适合通过 UI 完成，例如：

• 查看 worklist
• 审核 diff
• 选择执行范围
• 人工拍板验收

有些操作则更适合通过 CLI 或 skill 完成，例如：

• agent 直接调用
• 批量化执行
• 编排到自动化流程里
• 在不同模块之间传递结构化输入输出

所以如果一个平台只能通过 UI 使用，它对 agent 来说就不够原生。

如果一个平台只能通过 CLI 使用，它对人类协作和审核又不够友好。

更成熟的做法应该是：

同一项能力，既能通过 UI 触发，也能通过 CLI 或 skill 调用。

这样平台能力才真正能同时被人和 agent 消费。

十、严格的读写权限控制，不是附加项，而是平台底座

如果 AI 平台真的能够读代码、改代码、跑命令、跨项目访问资源，那么权限控制就不能只是后补的安全功能。

它必须一开始就是平台底座。

我会尤其看重这几类控制：

• 哪些目录只读，哪些目录可写
• 哪些仓库可以访问，哪些不可以
• 哪些命令可以直接执行，哪些必须审批
• 哪些能力只能读事实源，不能直接改动
• 哪些高风险动作必须经过人工确认

这里不能只做成“是否 FULL 权限”的二元开关。

真正有用的权限模型应该更细：

• 路径权限要能区分不可见、只读、可写、可创建和可删除
• 命令权限要能区分禁止执行、允许执行、需要审批后执行
• 同一个命令还要能按参数、工作目录和目标路径继续收窄
• 不同任务阶段可以有不同权限，例如调研阶段只读，落地阶段才开放指定路径写入
• 临时提权必须有范围、理由、有效期和审计记录

也就是说，平台不应该只问“这个 agent 有没有全权限”，而应该能回答：

• 它能读哪些路径
• 它能改哪些路径
• 它能运行哪些命令
• 哪些命令必须先让人确认
• 哪些能力只是本次任务临时开放

FULL 权限可以作为极少数场景下的兜底模式，但不应该成为默认协作模型。

一个我觉得很合理的默认模型是：

一个 agent 负责一个项目。

也就是说，对这个 agent 来说：

• 它对自己负责的项目有写权限
• 对相关项目，尤其是直接依赖项目，只有读权限
• 如果没有额外授权，就不应该跨项目直接写入

这个边界非常重要。

因为很多研发任务确实需要跨项目理解，但不代表每个 agent 都应该天然拥有跨项目写权限。

更稳的做法通常是：

• 写权限按项目边界收敛
• 读权限按事实源和依赖关系适度放开

这样 agent 才能既拿到足够上下文，又不会轻易把局部任务扩散成跨仓库副作用。

这不只是安全问题，也是工程质量问题。

因为如果读写边界不清楚，AI 很容易：

• 误改不该改的文件
• 越权访问不该访问的项目
• 在错误位置写入产物
• 把一次局部任务扩散成全局副作用

一个真正能进入企业研发链路的平台，必须把“能看到什么、能改什么、在哪种条件下能改”定义得非常明确。

十一、跨项目功能开发，应该有协调者来组织多个 agent

如果一个功能本身就是跨项目的，例如：

• 前端改动同时依赖后端接口调整
• SDK 改动同时依赖协议仓库更新
• 平台能力改动需要多个仓库一起联动

那更好的做法通常不是放一个“全权限 agent”直接横跨所有项目处理。

我更倾向于一种分工更清楚的方式：

• 每个 agent 负责自己的项目
• 协调者负责拆任务、分配上下游关系、同步状态和组织验收

也就是说，跨项目功能开发更像是：

• 一个协调者
• 多个项目 agent 联合开发

而不是：

• 一个 agent 横穿所有仓库一路改过去

因为跨项目任务真正复杂的地方，往往不只是“改几份代码”，而是：

• 哪个项目先改
• 哪个项目的产物是上游输入
• 哪个项目只需要读取事实源
• 哪个项目需要真正落代码
• 哪些联动点必须一起验收

这些事情本来就更像编排问题，而不是单 agent 自治问题。

所以如果平台真的想支持跨项目研发，它就应该显式支持这种协作模型：

• 项目级 agent
• 跨项目协调者
• 可见的上下游依赖关系
• 可追踪的跨项目 diff 和验收状态

十二、平台界面不该只是一段对话

如果 AI 软件研发平台的主界面只有聊天框，我会觉得它的形态还太早期。

因为研发活动天然有很多结构化对象：

• 任务
• worklist
• diff
• contract
• 测试结果
• review 意见
• 验收状态

这些东西如果都折叠成自然语言对话，会带来两个问题：

• 事实越来越难审核
• 状态越来越难追踪

所以更成熟的平台界面，应该把这些对象显式化。

例如：

• 让任务和 worklist 可见
• 让 diff 和测试结果可直接审核
• 让上下游依赖和相关项目可追踪
• 让失败原因、阻塞点和待人工决策点显式暴露

我还会进一步要求：

界面不只是把对象列出来，而是要把强相关证据 inline 放在一起。

比如：

• 描述一个功能时，旁边就能看到相关验收测试内容和最近结果
• 描述一个文件或数据结构时，旁边就能看到对应代码和示例
• 看一条 review 意见时，旁边就能看到相关 diff、相关规则和修复后复查结果

因为研发里很多误判，不是因为信息不存在，而是因为信息散在太多地方，读者需要自己来回切换和手工拼装证据链。

如果平台界面只能做到“这里有文档、那里有代码、另外一处有测试结果”，那它仍然是在把集成工作留给人。

这件事的重要性，有点像附屏对工作效率的提升。

附屏本身并没有创造新的信息，但它减少了窗口切换，让人可以把主任务和参考材料同时放在视野里。AI 软件研发平台里的上下文聚合也是类似的：它不只是把信息存起来，而是减少人工在多个页面、多个文件、多个命令输出之间来回跳转的成本。

比如一个任务项的工作视图里，最好能同时呈现：

• 任务项原文
• 验收标准和验收标注
• 对应验收测试的运行结果
• 失败项、阻塞项和需要人工确认的点
• agent 对当前状态的摘要判断

这些内容不一定要全部默认展开。很多时候可以默认收缩，只把状态、结论和异常点露出来，让用户需要时再展开细节。但它们应该在同一个上下文里可达，而不是让用户在多个文件和界面之间反复跳转。

更好的做法应该是让人和 agent 在一个阅读面里就能看到：

• 当前结论
• 结论对应的真实代码
• 结论对应的测试和结果
• 结论是否已经被最新变更影响

这样平台才不只是一个信息入口集合，而是真正帮助人完成判断的工作台。

换句话说，聊天框可以是入口，但不应该是平台的全部。

十三、我更期待的平台，不是替代工程师，而是放大工程判断力

我对 AI 软件研发平台最核心的期待，不是“以后工程师可以少思考”，而是：

平台能把工程师最重要的判断力放大出来。

具体来说，就是让人更容易做到这些事情：

• 快速拿到完整上下文
• 看清真正重要的抓手
• 把不重要但耗时的部分交给 AI
• 对关键 contract、测试和架构做重点审核
• 在出现偏差时快速定位并纠正

如果一个平台只能让 AI 更快地产生更多内容，但不能让人更快判断什么重要、什么可信、什么该验收，那它最后大概率只是更高级的噪音放大器。

结尾

我不觉得 AI 软件研发平台的核心竞争力会只是模型接得多不多，或者生成速度快不快。

真正的分水岭，可能在这些地方：

• 是否真正理解研发工作流
• 是否真正提高迭代速度
• 是否把上下文工程做成平台能力
• 是否把 contract 和 verification 放在中心
• 是否优先让传统程序处理确定性问题
• 是否支持能力模块化与编排
• 是否同时支持 UI 和 CLI / skill 双轨触发
• 是否具备严格的读写权限控制
• 是否支持“项目 agent + 协调者”的跨项目协作模型
• 是否区分本地开发和正式部署
• 是否提供高可读性的文档与事实源入口
• 是否让工程师的领域判断力被放大，而不是被绕开

所以如果要我用一句话总结：

AI 软件研发平台，不是在研发流程旁边放一个 AI，而是围绕 AI 重新设计研发流程本身。