公司架构师

创始人要把脑子里的公司落到文档时，常见的失败方式是一次性写出一份二十页的商业计划书，写完就没人再碰它，半年后和实际情况完全脱节。这份计划书要么是散落在 Notion、Word、飞书里的段落，要么被锁在 PPT 的排版里，人和模型都无法直接读取。

它解决的问题

把公司当成一个代码项目来管理：每个概念是一个 .md 文件，文件名就是概念的 ID，正文里用 Markdown 链接把概念连成图。这样同一份文档人可以直接读，AI Agent 可以直接解析，不需要再写一层翻译脚本。

工作方式

公司架构师（Company Architect）把自己定位为创始人的首席参谋，把战略、财务、营销、运营、系统架构这些角色合并到一个 Agent 里，然后严格按 12 个阶段推进：

1. 00-fundacao 只问 3-5 个问题，拿到答案前不会生成任何概念文件
2. 依次推进战略、市场、财务、商业、营销、产品、运营、技术、人员、法务、治理
3. 每完成一个阶段就跑一次校验，再生成索引，把进度写回 index.md

每个概念文件必须带 YAML frontmatter 和强制性 type 字段，关系只允许写在正文的 Markdown 链接里，不能塞进 frontmatter 的数组——这是它反复强调的规范，因为这样才能保证文件被任何工具读取时结构一致。

生成节奏上，它不会一口气写完。每个阶段都会先展示要创建的文件和 type，等你确认后再写盘。根目录的 index.md 始终是仪表盘，标注 12 个阶段的状态，log.md 则记录每一次决策的时间戳、被否决的替代方案和理由。

实际输出

最终产物是一个符合 OKF v0.1 规范的 bundle：目录里全是 .md 文件，没有运行时依赖，不需要装 SDK。随附的三个 Python 脚本只用标准库，分别负责脚手架生成、规范校验、索引更新，脚本内嵌样例数据，带 --help 可以直接跑。推荐流程是先 scaffold_bundle.py 建骨架，然后逐阶段访谈、写概念、跑 okf_linter，最后 index_generator 重建索引。

适用边界

这套设计假设一件事：你能回答那些访谈问题。它不会替你发明市场数据、财务数字或法律条款——在信息缺失时它会给出 [ASSUMPTION] 标记并继续，但假设写得对不对，仍然是你的责任。

另一个现实限制是过程成本。每个阶段至少一轮问答加一轮确认，12 个阶段跑完对创始人的注意力要求不低。适合正在从零搭建公司、或者要做一次系统性复盘的团队，不适合只想快速出个 demo 的场合。

如果你的环境没有磁盘写入权限，它会把每个文件以代码块形式返回并附上路径，这意味着你需要自己落盘——在多人协作或 CI 里，这个约束要提前考虑。

需要明确的是，bundle 本身不含可执行逻辑。它是一个标准化的知识仓库，不替代真实的 API 集成、数据管道或部署流程，只是把它们的存在和关系记录下来。

最后一个小点：输出语言是英文，但它明确要求内容写得 dense 且直接，所以不适合那些希望文档读起来像营销文案的团队。