从已有实践走向可复制交付
实践 / 建议从已有实践走向可复制的研发方式
你们已经具备知识聚合、技能分发、规格驱动、任务编排、独立验证和诸葛运维入口。 下一步最有价值的工作，是把这些能力连接成可重复交付、可接管、可追溯的日常研发流程。 推广单位建议采用“团队 + 代表服务 + 一类任务”，逐批扩展到同类工程。
代码生成提速后，应同步提高可验证能力、验证资源和人审质量。 人持续掌握目标、判定基准、系统约束、风险决策与接管能力；机器承担适合自动化的重复验证和有界执行。 详见 人机验证协作专章。
本文怎样使用“经验”这个词
| 标签 | 含义 | 可以据此做什么 |
|---|---|---|
| 已核对 | 本地固定提交中的实现、配置或 CI 接线 | 复用设计，安排运行验收；不等于本次跑通过 |
| 案例记录 | 仓内案例、平台介绍或方案记载的做法 | 作为经验线索，接入时复验关键假设 |
| 用户确认 | 诸葛与部门虚机、研发双入口与 GitLab SSOT、多源知识萃取和定期增量更新 | 在这些既有条件上设计运行与学习方式 |
| 建议演练 | 本报告提出的合同、步骤和目标 | 经过试点与评审后落地，不能计入已实现成果 |
本轮没有执行业务迁移、生产巡检、线上修复、部门虚机部署或完整业务 CI。 下文“推荐”“应”“验收”均指建议；版本固定的源码、案例和公开原文列在证据索引。
公司自己的六个可复用样本
| 样本 | 已有做法及直接价值 | 推广前要补的部分 |
|---|---|---|
| ai-wiki / wiki-bot | 多仓知识汇聚、领域导航与来源；能承接 udobj 知识 | 人工与生成页边界、元数据发布保真、迁移后的消费者切换 |
| fs-ai-hub / TeamAI | 角色、Project、命名空间、维护责任与分发设计 | 更多团队登记、固定包、冲突检查与真实安装验收 |
| FSpec / feeds | 规格、公司规则对象、阶段产物、独立 Validator | 规则源版本追踪、交接索引刷新、测试退出语义校准 |
| fs-developer-platform（IDP） | Issue 的 Rn/Tn 到 SHA/证据映射，反恒真与测试归属 CI | 托管 runtime 适配、check/fix 分开、身份与服务端门禁验收 |
| fs-egress-proxy | VERIFY 清单、测试报告检查、负向样例、长时间稳定性测试 条件 | 本地聚合入口与 CI 对齐，观测阈值校准 |
| bug-finder / 诸葛 | 专业取证、facts/decision 分离、值班接管与能力评测 | 接通修复合同、真实回放、生产恢复信号与权限隔离 |
建议把这六类样本整理成公司内的“可运行参考工程 + 示例任务 + 验收证据”。 团队接入时从最接近自己的样本复制适配层，避免从空白提示词开始。
阅读路径
- 团队负责人：先看资产分工、冲突处理、团队接入和推广验收。
- 开发与 QA：看日常剧本、棕地改造、测试与证据、踩坑卡。
- 平台与 SRE：看架构三图、运行时、自主巡检修复、观测与接管。
- 知识与技能维护者：看知识迁移、能力发布、行业对照和来源索引。
本节依据： fs-ai-hub 规范、IDP 入口、Egress 入口；全部版本见证据索引。