一、这次沉淀的结论
AI 原生组织不是“给旧流程加一个 AI 插件”，而是把产品交付改造成“统一事实源 + Agent 协作 + Skill 沉淀 + 自动验证 + 人工门禁”的 operating model。
组织结构
建议采用“产品作战单元 + AI 交付平台部 + 轻量治理委员会”三层结构。
交付闭环
从需求进入云效开始，经原型、任务契约、Agent 构建、自动验证、验收、发布、手册/视频和反馈回写闭环。
经营对象
把群消息、附件、任务、项目、风险、周报、指标和人员贡献转成可追踪对象，而不是再加一轮周会。
底线
人负责方向和禁区，Agent 优化执行方式；高风险发布、权限、数据、安全和客户生产环境保留人工门禁。
二、来源处理
| 类型 | 数量 | 处理方式 |
|---|---|---|
| DOCX | 6 | 通过 OOXML 文本抽取为 Markdown，原件只登记路径和 SHA256。 |
| Markdown/TXT | 7 | 复制为 evidence 文本，稳定 Wiki 只吸收高信号方法，不全文搬运。 |
| 2 | 用 `pdftotext` 派生文本，作为 C 级参考信号。 | |
| PPTX | 2 | 抽取幻灯片文本，登记为大文件资产。 |
| XLS/XLSX | 4 | 抽取表格文本，保留结构线索，格式以来源文件为准。 |
完整列表见 source-index.csv 与 large-source-assets.csv。
三、建议的组织模型
| 层级 | 名称 | 职责 | 输出物 |
|---|---|---|---|
| L1 | 产品作战单元 | 围绕产品线定义业务价值、原型、验收标准和上线判断。 | 原始需求、原型、验收清单、上线指令。 |
| L2 | AI 交付平台部 | 维护 Codex/Hermes/OpenClaw/云效链路、Prompt/Skill、自动测试、发布门禁。 | 任务契约、Agent workflow、质量门禁、复用资产。 |
| L3 | 轻量治理委员会 | 负责架构红线、安全合规、数据权限、关键模块灰度与复盘。 | 红线清单、风险裁决、发布审批、复盘规则。 |
四、端到端闭环
1. 需求进入云效
2. 原型构建
3. 任务契约
4. Agent 执行构建
5. 自动化验证
6. 测试环境验收
7. 发布就绪检查
8. 产品上线指令
9. 自动发布
10. 手册/小视频
11. 反馈回写
12. Skill/规则沉淀
第一阶段的关键不是让 Agent 完全自治，而是把任务契约、上下文包、验证门禁、状态回写和发布边界做成标准件。
五、项目内落点
| 资产 | 路径 | 用途 |
|---|---|---|
| 稳定 Wiki | standards-stack/llm-wiki/ai-organization-methodology/README.md |
后续问答和组织设计的知识入口。 |
| 项目 Skill | standards-stack/agent-skills/skills/ai-organization-operating-model/SKILL.md |
后续遇到 AI 组织/交付组织/项目经营中台问题时加载。 |
| Eval | standards-stack/agent-skills/skills/ai-organization-operating-model/references/evals.md |
防止 skill 过宽或漏载。 |
| 证据目录 | work/2026-05-29-ai-organization-methodology-intake/ |
保留 source index、抽取文本、summary、ROUTING_NOTE 和本 review。 |
六、需要 Jack 确认
- 是否认可三层组织结构作为后续 AI 组织问题的默认框架。
- AI 交付平台部应放在产品开发部内部，还是作为跨产品/研发/交付的共享平台。
- 首个试点链路选 Store、AI API、AI App、智慧食堂交付资料，还是云效/微盘项目经营中台。
- 哪些事项可以走 AI 高速通道，哪些必须进入轻量治理委员会审批。
七、反模式
- 禁止 把“会用 AI 写代码”当作 AI 原生组织。
- 禁止 把群聊、会议纪要或口头安排当作唯一事实源。
- 禁止 在没有测试、门禁和负责人时承诺无人值守上线。
- 禁止 把外部行业趋势直接写成康比特已验证事实。