夜雨聆风个人理解，不成体系，仅供参考
不要和模型争夺“怎么做”，而要建设模型永远需要的“环境、反馈和约束”
让人负责不可委托的判断，让 AI 承担可验证的执行
AI 相关工作 要利用好模型能力，但 永远不要站在 模型能力 演化主线上
利用好模型能力
正例：我们是如何达到稳定95%+ UI还原的？
人的职责边界（手工清理设计稿）
利用好模型的 Vision 能力
self-verification 能力
反例：为什么 依赖于传统视觉算法的 D2C 还原/检测 方案，一定会撞墙
AI 应用相关的工作，重要的就是要弥合 通用的 AI 能力 如何 在私有工程上获取反馈（通过 知识 + CLI）
工程领域的 bitter lession：站在模型能力演化主线上的工作，一定会快速失去价值，被模型自身能力撞飞
模型能力演化的主线是：从"需要人给流程" → "人给目标，模型自己规划路径"。
任何试图在中间阶段用固定流程框架去约束模型的工作，都是在跟这条主线逆向而行。workflow 本质上是在模型还不会自己规划的时候，用人写的规则替它规划。等模型会自己规划了（GPT-5.6 发布后 superpowers 卸载潮就是信号），workflow 就变成了枷锁。
无团队 / 领域知识 的 workflow价值在快速降低
和模型能力演化的夹角
工作/创业方向要有一定夹角（夹角大了，做不出来；夹角小了工作很快被模型撞烂）
对AI Dev 应用来讲，做模型能力演化主线上的"基础设施"，而不是"中间层"。
知识、CLI、编译速度、可测试性、可观测性——这些是底座，模型再怎么进化都需要底座。
偏通用性质的 流程编排、步骤拆解、Spec 驱动——这些是中间层，会被模型逐步吞掉。
带有团队特点 和 私域知识的 流程编排会简化，但是提供了增量，不会完全消失
层次 | 典型内容 | 长期价值 |
Model | reasoning / coding / planning | 快速演化 |
Workflow | 固定流程 / step-by-step | 容易被模型逐步吞掉 |
Harness | knowledge / CLI / test / build / observability | 长期存在 |
Engineering substrate | compiler / runtime / mock / CI / permissions | 长期存在 |
真正应该投资的是 Harness。知识 + CLI + 编译速度 + 可测试性 + 可观测性
这几个东西有一个共同特点：模型越强，它们反而越重要。
因为模型越强，就越不需要你告诉它：第一步做 A，第二步做 B，第三步做 C。
但你必须让它能够： 看懂这个仓库 → 调用工具 → 修改代码 → 快速执行 → 获得真实反馈 → 修复 → 再验证。
所以好的 AI 工程环境，很可能不是“Workflow 很复杂”，而是：
模型面对一个非常好的 Engineering Environment。
为什么编译速度在AI时代非常非常重要？
AI Agent 时代，工程基础设施会出现一个以前没有这么严重的问题：验证本身可能成为瓶颈。
如果一次编译构建耗时30分钟，Agent 很强也没用。
所以：AI coding 的核心生产力，很大程度上取决于 feedback latency。
编译速度：我认为其实应该提升到非常高的位置。
甚至可以说： AI时代，Engineering Velocity ≈ Agent Intelligence × Feedback Bandwidth
AI Workflow 设计理念
个人对AI Dev workflow 的设计理念：
尽最大可能利用好 AI 能力
为AI 提供环境反馈辅助，辅助AI完成 dev-verification 闭环
明确AI的边界，强调人的作用，不要害怕用人，绝不强调“低含人量”
AI 在局部技能超过人；全局判断力，模糊性处理能力全面落后与人
AI Verification 是 workflow 的核心
严肃工程开发，需要层次化的验证体系
测试金字塔理念主体依然没有变化
AI 时代最稀缺的东西可能不是生成能力，而是 Evaluation 能力。
模型越来越便宜、越来越强。但是：什么叫正确？依然是一个非常昂贵的问题。
AI Dev 中的 UX 设计
与不少追求 “低含人量”的 AI工作相比，我对AI相关工作流 设计追求的是：合理分工，特定阶段要 “高含人量”（人要负责把控方向，心中有数），特定阶段要“高含AI量”（人要轻松，苦力活都给AI）
有模糊性的，需要判断的尽量交给 人
现阶段 即使AI 能做，也要人做确认；直到有一天AI 可以长期稳定的完成这个工作才考虑交给AI
细节性的，流程性的 能交给AI 就交给 AI
理想AI Dev workflow （建设方向）
1. 人在两头：前面负责需求边界理解，核心技术方案判断，技术方向把控；后面做简单检查
AI 在中间：自动的完成整个需求，并尽量做到完善的验证，交付经过充分验证的产物
AI / 人 交接：
人 -> AI: 无模糊性的需求，充分且必要的 上下文；
AI -> 人：经过多轮自我验证的 代码，人做下简单的review 和 check
AI 时代 人工作的内容和方式：
需求交付：人在两头，在前：负责提供无歧义，无模糊性的需求；在后：简单验收； --- 交付研发团队价值
工程/基建 的AI 友好性：对标旧开发时代的架构，负责：知识，CLI，编译速度，单测/可测试性，集成测试等能力建设，核心机制的可观测性，可Mock能力建设；--- 打好AI 工作地基
AI 生码如何做到 质量内建？
标准项 | 指标 | ||
1 | 逻辑正确性 | 单测 | 单测+组件测试覆盖率 >= 90% |
2 | 集测 | 全量BDD Case通过，含全量正常/异常/边界路径 | |
3 | E2E 测试 | 端到端验证 | |
4 | 代码规范性 | 代码Lint检查 | Lint零Error |
5 | TS编译校验 | TypeScript编译通过 | |
6 | 工程规范 | 符合Gundam工程规范 | |
7 | 代码质量 | 异步异常处理 | 所有异步调用都有catch处理，如bridge |
8 | 可观测性建设 | 埋点、雷达、日志完备 | |
9 | 代码注释 | 类/方法/变量/枚举，及关键分支必须加注释 | |
10 | pitfall 不重复踩坑 | 已经沉淀的 pitfall，全部召回 |
如果AI每次产出的代码，都符合这个标准，是不是就靠谱很多 ？
AI 时代 代码设计的可观测性设计 重要性进一步提升了
代码设计可观测性 在 AI时代更重要了，尤其是大家对细节掌握快速下降的情况下
典型的可观测性使用方式：
契约 ---- 检查代码的invariant condition，precondition 等，自测阶段提前发现问题
报警 ---- 核心异常主动上报，线上及时召回问题
日志 ---- 出现问题时排障使用
埋点 ---- 业务埋点
有效的提示词风格：给目标，给约束，给工具，给知识；不要给流程
现阶段的AI能力已经足够了，甚至是 ds-v4-flash 级别的模型
流程一方面控制了模型的路径，一方面限制了模型能力的发挥
不是完全决绝“给流程”，而是尽量的提供反馈方式，而不是手把手的指导
AI Agent 设计原则：
Constraint > Procedure
Feedback > Instruction
Goal > Workflow
为什么 SDD/AI Dev Workflow 应该是 Team-Specific 的
每个业务团队都应该定制自己的专属 AI Dev Workflow；
AI 基建团队应该提供一个好的 AI Engineering Environment；
SDD 不解决需求模糊性，以及需求到方案之间巨大 gap 的本质困难
这个困难来源于业务已经存在的上百万行代码
存在于人与人沟通，信息传递
存在于落到纸上总是很难全部表达清楚
存在于多职能角色每个人都只有自己的部分上下文
这个只能靠团队/个人 自己来解决
抛开需求到技术方案的 gap 来看，后续 implementation，和 verification
一方面是工程自己的内功：编译速度够不够快，代码有没有可测试性，能不能跑单测。
另一方面这个 implement 和 verify 的机制，在模型自身能力进化主路线上，在 agent 原生能力主路线上，例如，goal 模式，例如 GPT5.6 出现后的 superpowers 卸载潮。所以作为流程约束的 通用型 SDD 前后问题都不解决，本质上没啥增量，而且会被模型和 agent 能力演化，快速撞穿
这部分核心在于 工程自身（例如：编译速度，能不能跑得动单测），而不是流程
此外，即使同一个仓库开发的两个团队，共用一套 sdd 流程，可能也是橘生淮南，工作流带着强烈的团队风格和基因
有的团队例如偏运营活动性质的前端项目，单个项目复杂度不高，但是需求量级大，会追求快速迭代，希望减少人的参与，AI 接管更多的工作，以此来提高产出
另外一个团队，需求复杂度高，影响范围大，希望人做更多的整体把控，追求稳健
这样两个在同一个工程下开发的不同团队，AI Dev 工作流因为团队基因的不同，工作流也可能完全不一样
通用 SDD 不能提供合理的心智模型
在brainstorm 这种 AI - AskUserQuestion -> 人 的使用体验下，需求到 方案制定这个对人要求很高的阶段变为了
AI 的思考替代了人的思考，不是人的主动思考，而且被动回答几个问题；AI 写的东西看起来都是 貌似“挺合理的”，走纯SDD 流程，人 丢失了 “我对方案心中有数” 的基础掌握
业务团队定制的SDD ，已经包含了团队很多的领域知识，团队惯例和规范，适用性会好很多（vibe planing 也可以成为 团队级 SDD 不适用时候的 备选使用姿势）
AI 基建团队应该提供：Goal，Plan，Spec，TDD，Review，Verification 这些 primitive。业务团队自己组合。
这样 AI 基建团队提供的是：能力组件，而不是：标准答案。
AI 时代，哪些应该团队间共享，哪些应该团队内自建
真正有通用价值的
价值对齐：拉齐理念永远是最难的
这方面在知识库方案上特别明显，内部知识库工具可能超过了10个，真正有效的知识有多少？知识重要，还是知识库工具重要？
工程自身的CI/CD 基建，代码质量
代码的可测试性，可理解性，知识融合（甚至可以是注释）
编译构建速度，单测，集测能力，场景触达能力
原子CLI
从研发视角，所有 基建型，核心机制型的SDK和framework，应该自带 给AI的 CLI，提供可观测性 和 Mock能力
权限校验
最大化，最简化的让大家access 能 access的信息；保留审计和控制能力
团队隔离的coding agent 配置
解决基础的冲突问题
一体化的 agent 打包体验方式
完整的 AI 工具提供，应该包含了，CLI + SKILL + SubAgent + Model 甚至 Coding Agent
提供打包发布工具，提供完整的开发体验
每个需求 跨角色维护的 Context
AI 能够持续稳定质量输出的 特定领域 工作流
例如 mirror code
无通用价值的
workflow -- 带有强烈的团队风格，领域知识诉求 和 上下游沟通结构，泛化性本身就不够高
对 AI 基建团队的个人预期
想办法不限制大家使用姿势的情况下，把效能数据采集上报 --- 组织要求
openspec 等随便选一个(最好是轻量级的sdd)，作为兜底推荐，不做深度定制，推荐各个团队自定义工作流，或者使用goal，plan 等；--- 永远不要站在 模型能力发展的方向上
打磨仓库 harness（知识，编译速度，单测/TDD，E2E，甚至是架构标准） --- 工程内功
围绕主站做完善+好用的CLI（很重要，新模型主要是给目标和给工具就可以）（每个基建sdk自带 cli + mock能力，例如featureFlag，网络请求，preference等） ---- 工具/基建 内功
统一的权限校验机制 能access 的透明access，全局随便审计；---- 权限要求
开发团队内统一，团队间隔离的 知识/skill/subagent 方案 --- 应对单仓多团队，多仓多团队的开发场景
从各个团队发现类似 mirror code 这样的 特定领域相对确定的 workflow，打磨好，推广给整个团队 --- 有稳定效果的 特定领域领跑
尝试找到跨角色的 工作方式，不要仅关注研发一个环节
NPS 才是AI Devops 效果的 的试金石
敢做 nps 的 AI 相关 工作，才是真的有效工作
其他的指标要不然过于主观，要不然过于间接，受其它因素影响较大
