AI Engineering
产研团队 Skill 的价值：把个人 AI 提效变成组织能力
AI 编程最先带来的，是个人速度提升。但产研团队真正需要的，不是每个人都多一个会写代码的助手，而是把需求、方案、拆解、编码、测试、评审和知识回写做成可重复的组织能力。
Skill 的价值就在这里。它不是一段更长的提示词，而是把团队已经认可的工作方式、输入输出契约、上下文边界和检查规则，压缩成 AI 可以稳定调用的流程资产。
单兵提效之后，瓶颈会回到协作
当每个工程师都能用 AI 更快写代码时，团队的问题不会自动消失。需求仍然可能说不清，技术方案仍然可能偏离架构，任务拆解仍然可能粒度过大，代码评审仍然可能只看语法不看边界。
如果没有统一流程，AI 会把这些不一致放大。一个人用自己的提示词生成 PRD，另一个人用另一个 agent 拆任务，第三个人让模型直接改代码，最后得到的是更快的混乱。
先收敛六个核心 Skill
产研主链路可以先从六个 Skill 开始：write-prd、write-tech-design、breakdown-tasks、coding、test、code-review，再加一个固定的 update-context 闭环。不要一开始做几十个命令，先让一条主链路跑稳。
- write-prd：从沟通记录、需求线索和知识库生成目标、业务规则、异常场景和验收标准。
- write-tech-design：从 PRD、架构约束和模块上下文生成技术方案、接口契约、数据变化和风险点。
- breakdown-tasks：把方案拆成可独立交付的任务单元，每个任务有输入、输出、依赖和验收标准。
- coding/test/code-review：围绕任务单元形成编码、单测、结构审查、修复的闭环。
- update-context：开发完成后把新增业务规则、接口变化、模块边界和 ADR 建议回写到知识库。
上下文要分层，不要都塞进一个文件
团队 Skill 能不能稳定，关键看上下文加载是否准确。L0 是项目级稳定规则：架构、技术栈、编码规范、核心 ADR、领域术语。L1 是模块级知识：模块职责、接口契约、数据模型、状态流转。L2 是任务级材料：本次 PRD、方案、任务卡、diff、测试结果。
不同 Skill 应该加载不同层级。技术方案至少需要 L0 和 PRD；编码需要 L0、相关 L1 和任务 L2；CR 需要 diff、编码规范和架构约束。上下文加载不准，输出越完整，跑偏越隐蔽。
每个 Skill 必须有输入输出契约
“帮我生成文档”不是 Skill。可复用的 Skill 要说明读什么、产出什么、哪些字段必填、哪些内容不能编、失败时怎么处理。输出必须能被下一个 Skill 消费，否则它只是一次性文字。
PRD 里没有业务规则和验收标准，技术方案只能靠猜。技术方案里没有接口契约和风险点，任务拆解就会变成空泛 TODO。任务里没有依赖和验收标准，Coding Agent 就很难独立执行。
update-context 是团队能力的复利
很多团队一开始 AI 效果很好，几周后逐渐变差，本质是知识库没有跟着代码更新。update-context 应该成为固定动作：读 diff、PRD、方案和测试结果，整理新增规则、接口变化、隐式状态流转和文档缺口。
这既是在建设新流程，也是在还旧账。存量系统最重要的规则往往藏在代码分支、旧 PR、线上事故和口头约定里。让 AI 先整理，人再审核，是比较可控的路径。
从哪里开始
- 选一个高频交付模块，先逆向模块结构和关键规则。
- 跑 write-tech-design → breakdown-tasks → coding/test/CR → update-context 的最小闭环。
- 用人工修改比例、任务可独立执行率、CR 有效问题数、下轮上下文解释成本来评估 Skill 质量。
- 稳定后再补 write-prd 和更多专项 Skill。
高可用 Skill 会成为团队新的工程资产。它把团队经验从个人提示词、聊天记录和口头习惯里抽出来，变成可维护、可审查、可复用的协作层。AI 越强，团队越需要这层工程化约束。