项目存在的理由
Company OS 试图回答一个更难的问题：AI 生产力如何在公司内部被正式配置、受治理地推进、沉淀为能力，并最终服务于长期企业价值，而不是停留在一次次“帮我做这个任务”的指令层。
Blueprint
把源文档里的结构，翻译成真正能被官网访问者理解的系统蓝图。
这页不是仓库 Markdown 的镜像，而是官网版本的蓝图说明。它保留原始设计意图：Company OS 是一个用于配置 AI 生产力的 company operating system，而不是 all-purpose agent 或 loose chat swarm。
目标函数不是单一效率，而是长期企业价值
- Survival 是硬约束，不是“以后再考虑”的外部条件。
- Profit 是燃料，但不是唯一目标。
- 可迁移的能力资产比短期输出更有战略价值。
- 扩张必须建立在首个业务单元稳定之后。
系统由四层组成
Control Plane
公司级规则、portfolio 管理、机会 triage、stage gates、capability approval。
Business Units
围绕单一 ICP、单一决策链和单一 evidence family 组织的 repeatable decision engines。
Shared Services
memory、risk-gates、router、ledger 等共享底座。
Human Boundary
人类保留宪法设定、资本配置、签名身份、异常裁决和最终审计权。
为什么蓝图强调 formal objects
聊天记录对执行来说太松散，对治理来说太脆弱，对产品化来说太不可组合。Company OS 因此把公司运行建立在正式对象之上：
OpportunityBriefWorkOrderArtifact RecordOutcomeCapability UpdateLedger Event
Opportunity → Brief → WorkOrder → Artifact → Outcome → Capability Update → Ledger Event
蓝图里真正有复利的，是这些闭环
Execution Loop
WorkOrder → route → risk gate / review → outcome
Artifact Loop
WorkOrder → artifact register → review → artifact status update
Learning Loop
Artifact + Outcome → Capability Update proposal → Control-plane approval
Human-Gate Loop
高风险动作进入明确审批面，而不是被系统“悄悄自动通过”。
第一业务单元：Demand Intelligence
首个 active business unit 不是随意挑选的服务，而是一个能够验证 Company OS 方法论的切口：帮助独立开发者和小型 SaaS / AI 团队判断下一步该追哪条 demand wedge。
- 它卖的是 decision clarity，而不是 generic research reports。
- 当前已经有 intake schema、research checklist、evidence taxonomy、promotion gate 与 deliverable template。
- 结构化 recommendation draft 已经可以产出 primary wedge、backup wedge、limitations 和 two-week validation plan。
当前必须讲清楚的边界
- 这是一个已验证的治理型原型，不是已经自治经营的完成态公司。
execution_worker仍被保留给未来具体执行阶段。- 研究路径依然是 bounded, provenance-preserving 的 source ingestion，而不是开放式全自动市场情报采集。
- 人类仍然拥有法律主权、资本配置与最终审计地位。
继续浏览