🏠 home › concepts › ai-first-engineering
tags
[AI, 工程, 组织, 流程, Agent]
created
2026-04-14
updated
2026-04-28
sources
[raw/notes/creao-ai-first-engineering-2026.md, raw/notes/founder-park-creao-organizational-pivot-2026.md, raw/notes/zhao-saipo-work-experience-ai-skill-2026-04-27.md, raw/notes/anthropic-kat-wu-pm-shipping-cadence-2026-04-25.md, raw/notes/karri-saarinen-some-notes-on-ai-2026-04-26.md]

定义

AI-first ≠ AI-assisted。大多数公司把 AI 嫁接到现有流程（工程师用 Cursor，PM 用 ChatGPT 写 spec），效率提升 10-20%，结构不变。AI-first 是围绕"AI 是主要构建者"重新设计流程、架构和组织。差异是乘法级的。

核心转变：不再问"AI 如何帮助工程师"，而是"如何重构一切让 AI 来构建，工程师提供方向和判断"。

AI-Assisted vs AI-First 光谱

AI-Assisted AI-First
流程 现有流程不变，AI 加速个别环节 围绕 AI 重新设计整条流水线
架构 多仓库/微服务，人类可管理 Monorepo，让 Agent 看到全貌
组织 传统工程师层级不变 架构师（1-2 人）+ 操作员
效率增幅 +10-20%（加法） ×10+（乘法）
Vibe Coding 开 Cursor → prompt → 提交 → 重复 构建系统保证 AI 代码的稳定/可靠/安全，prompt 是一次性的

Vibe coding 产出原型，AI-first 产出生产系统。 两者的区别不是工具，是有没有构建保障系统。

瓶颈级联原则

当构建时间从月压缩到小时，相邻环节成为新约束。CREAO 识别出三个瓶颈：

瓶颈 旧节奏 新现实 解法
产品管理 PM 数周研究/设计/写 spec Agent 两小时实现功能 PM 进化为产品型架构师，以迭代速度工作；设计通过 prototype-ship-test-iterate 循环完成
QA QA 数天测试边角案例 构建两小时，测试三天 AI 构建的测试平台测试 AI 写的代码；验证必须与实现同速
人员 竞争对手 100 倍人力 25 人无法靠招聘追平 靠重新设计追平

如果三个系统（设计/实现/测试）中任何一个保持手动，它就约束整条流水线。 这是 Goldratt 约束理论在 AI 工程中的应用。

CREAO 选的是把瓶颈环节也 AI 化（三通道审查 + 自愈循环）。多数企业当前还停在"产能 AI 化但审核没 AI 化"的中间状态——这是瓶颈位移的普遍模式（→ bottleneck-shift-output-to-review 媒体案例：日产 20→200 篇 / 85% 不需人工 / 但审核成新瓶颈）。

架构决策：Monorepo 为 Agent 可读性

旧架构分散在多个独立系统，单次变更触及三四个仓库。人类可管理，Agent 不透明——无法看全貌、推理跨服务影响、本地跑集成测试。

统一为 monorepo 的核心原因：让 AI 能看到一切。

这是 harness-engineering 原则的实践：你把越多系统拉入 Agent 可检查、验证、修改的形式，杠杆越大。碎片化代码库对 Agent 不可见，统一的代码库是可读的。

自愈反馈循环

CREAO 的核心系统——每个工具处理一个阶段，无工具试图做所有事：

每天 9:00 UTC：Claude Sonnet 查询 CloudWatch → 健康摘要 → Teams
    ↓ 1h
分流引擎：聚类 CloudWatch + Sentry 错误 → 9 维评分 → Linear 工单
    ↓（含日志样本、受影响用户/端点、调查路径）
工程师验证 + 推修复 → 三通道 Claude 审查 → CI → 六阶段部署
    ↓
分流引擎重检 → 错误消除 → 工单自动关闭

去重：已有工单则更新，已关闭工单复发则检测回归并重开。

AI Code Review 三通道并行（Claude Opus 4.6）： 1. 代码质量：逻辑错误、性能、可维护性 2. 安全：漏洞扫描、认证边界、注入风险 3. 依赖：供应链风险、版本冲突、许可问题

每天部署 8 次，没有人类审查者能在每个 PR 上保持注意力。这些是审查门控，不是建议。

新工程组织：架构师 vs 操作员

架构师（1-2 人）

设计 SOP 教 AI 如何工作。构建测试基础设施、集成系统、分流系统。决定架构和系统边界。定义"好"的标准。

核心能力：批判 AI，而非跟随 AI。当 Agent 提出方案，架构师找漏洞——遗漏的失败模式、越过的安全边界、积累的技术债。

"批判 AI 的能力比生产代码的能力更有价值。"

这与 agency-framework 的时序框架完全对应：架构师行使 Agency（定义边界/设标准），Agent 在边界内执行，架构师再评估调整。

升级定义：架构师 = 通才 = 六边形战士

CREAO Clark Gao 在 2026-04 Founder Park 访谈中给出更具体的能力定义——架构师不是技术专家，是六边形战士：

能力维度 必须达到的程度
产品品味 能判断功能是否值得做、UI 是否符合用户心智
商业认知 能判断功能是否对齐商业主线、能否带来续订率/付费转化
行业理解 能判断竞品动态、识别真假需求、判断窗口期
技术掌握 能审 AI 写的代码、识别架构债、判断性能与安全风险

含义：传统"技术架构师"只覆盖第 4 项。AI-first 架构师必须四项都到一定程度——因为他要在 AI 自动生成的需求任务里做"挑哪些推进"的判断，纯技术视角不够。

这是 experience-over-knowledge 在组织角色定义上的具体应用——元能力（跨域判断）半衰期长，单域专精半衰期短。

架构师的工作流实例（功能迭代）

CREAO 给出一个完整的功能迭代实例，展示架构师在 AI-first 流程中的具体决策点：

AI 系统扫描行业动态
    └── 发现竞品上线 PDF 批量处理新功能
        └── 自动生成"我们是否要做"需求任务
            ↓
架构师确认（决策点 1）：
    - 是否对齐产品主线？
    - 是否有付费用户在做这件事？
            ↓ 通过
2 天上线（AI 实现 + 自动测试）
            ↓
AB test 一周
    - 使用时长提升 23%
    - 续订率提升
            ↓
架构师决策点 2：留下继续优化 / 下架

以前同样的事：需求评审会 + 排期 + 分配工程师 → 3 周以上。

关键变化：架构师不再是"分配资源的瓶颈"，而是"质量门控"——AI 生成需求 + AI 实现，架构师只在两个决策点（要不要做 / 留不留）介入。

操作员（其他所有人）

AI 给人类分配任务，而非人给 AI 分配任务。分流系统发现 bug → 创建工单 → 浮现诊断 → 分配给对的人。人调查、验证、批准修复。AI 制作 PR，人审查是否有风险。

任务：bug 调查、UI 细化、CSS 改进、PR 审查、验证。需要技能和注意力，不需要旧模式要求的架构推理。

经验钙化的实证

"初级工程师比高级工程师适应更快。"

初级工程师没有十年习惯要卸载，工具放大了他们的影响力。高级工程师两个月的工作被 AI 一小时完成，接受这一点需要放弃多年构建的稀缺技能的身份认同。

这精确验证了 agency-framework 的经验钙化理论：经验越成功越难放弃（沉没成本 + 身份绑定）。领域专精（"我懂写代码"）半衰期短；元能力（"我知道怎么评估"）半衰期长。

"适应性比积累的技能更重要"——在环境剧变时，这不是价值判断，是观察事实。

管理坍缩

之前 之后
管理时间占比 60%（对齐、开会、反馈、辅导） <10%
CTO 角色 赋能团队做架构工作 自己做架构 + 构建系统
工作模式 管理 → 授权 构建 → 每天 9AM-3AM 编码
人际关系 对齐会议、技术争论、消耗 更好——不再争论可以轻松完成的工作

传统 CTO 模型说赋能团队。但如果系统只需 1-2 名架构师，CTO 必须自己先做，证明系统可行，再让其他人进入操作员角色。

超越工程：全职能 AI 原生

如果工程数小时交付但营销花一周公告，营销就是瓶颈。 约束理论推论：全链条速度取决于最慢环节。

CREAO 将 AI 原生运营推入每个职能：产品发布说明从变更日志生成、功能介绍视频 AI 生成、社交媒体日更 AI 编排、健康报告从 CloudWatch 自动生成。

CREAO 案例数据

"我们用 Agent 构建了运行 Agent 的平台。如果产品能构建自己，它就行。"

完整时间线（自我证伪到 pivot）

CREAO 不是一次到位走到 AI-first 的——它经历了一次产品级 pivot，先证伪自己再重建。这个时间线本身是 pivot-speed-as-moat "中间态战略"的样本：

2025-01 底  公司成立
2025-06    招齐核心团队 6-7 人
2025-06    决定做 Vibe Coding 平台帮普通人搭 SaaS/CRM/工具软件
2025-09    Vibe Coding 平台上线
2025-09 后 自我证伪——"我们公司自己做出来的产品，自己人都用不起来"
            搭出来的应用没有专业 SaaS 公司做的好，bug 多调优长，自己用都复杂
            认知错误："给人构建传统工具" → 应该是"AI 给自己构建工具"
2026-02    Peter 重构开发团队，组织 AI-first 改造，1 个月重构整个新产品基础版本
2026-03-31 Super Agent 公开上线（agent.creao.ai）
2026-04    海外迅速扩散，ARR 4x，Founder Park 访谈

关键动作不是"产品 pivot"而是"先 pivot 组织"：在产品方向变之前，先把团队从开发流程到分工全部围绕 AI 重新打造，然后才用这套新组织重建产品。

自我证伪的勇气：Peter 在访谈中说，转型最难的不是方向"完全不行"（那时大家不反对），是"看起来还行但风险逐渐显现"——这是任何团队都会犹豫的状态。CREAO 选了"小是优势"逻辑——大公司多讨论一个月格局就变了，小团队应该当即决定。

Vibe Coding 自我证伪的元教训

CREAO 自身对 Vibe Coding 失败的复盘对整个 vibe-coding 赛道是反例级证据（→ vibe-coding-creator-motives 给该页加供给侧反例）：

  1. 供给方自己用不起来：vibe coding 平台公司的 marketing 团队搭不出能用的应用——这已经否定了"普通人能用 vibe coding 搭工具"的产品假设
  2. 认知错误的本质：以为应该"给人构建传统工具"，实际应该"AI 给自己构建工具"——AI 不需要 UI 不需要交互界面
  3. 市场结构判断：传统 Web 应用本身缺 AI 能力（agent 成熟后这类产品萎缩）+ SaaS 赢家通吃 + Lovable 已经在那
  4. Notion 已经走过这条路："给别人开发 App"是金字塔顶端少数人需求，低频
  5. Bolt/Lovable 越做越像下一代开发软件（加 Server / 客户端数据库），与 AI"让技术门槛越来越低"反方向

对 Sentino 的启示：Sentino 当前的"无技术客户通过 IoT App 创建 standalone agent"（sentino-agent）路径需要警惕——这条路是不是把"给普通人搭 agent 工具"当成产品，跟 CREAO 之前的 Vibe Coding 失败模式同构？区别可能在 Sentino 的目标用户是粉丝/陪伴/儿童家庭场景，不是知识工作者，差异化是否成立需要验证。

95% 操作定义

CREAO 给"什么叫真正的 AI-first"一个具体可量化的判断：

不是嘴上说说，也不是在现有流程里加几个 AI 工具，而是 95% 的工作都交给 AI 去做，人只做 AI 做不了的那 5%。

这是 AI-first 的操作性定义——任何团队可以拿这个比例自检。Sentino / 其他 AI 创业可以用"我们工作流里 AI 干掉的比例是多少"作为自我评估指标，不是用"我们用了几个 AI 工具"。

CREAO 内部： - 内部 marketing 团队 95% 工作流可用 AI 完成 - 99% 生产代码由 AI 编写 - 产品需求 AI 主动发现 + 提出，架构师只在两个决策点介入

Anthropic 视角的反向补强："95% 不是真正的自动化"

Anthropic Claude Code + Cowork PM Kat Wu 在 2026-04 Lenny Rachitsky 播客访谈给"95% AI 化"加了一个反向硬约束：

"如果一个自动化不能 100% 工作，那它就不是真正的自动化。 最后那 5% 确实需要更多时间，但你得投入这个精力，教 Claude 你的偏好，给它反馈，直到它能完全可靠地运行。"

两个判断不冲突，覆盖不同时点： - CREAO 95% 是起步门槛（团队整体 AI 化率达到才叫 AI-first） - Anthropic 100% 是单流程的合格线（任一被自动化的流程必须做到完全可靠才算"已自动化"）

含义：从"做到 95%"到"做到 100%"中间的 5% 才是"真正的工作"。Kat 观察到三种最常见的失败模式： 1. 有人从不自动化 2. 有人沉迷工具配置 3. 最常见：将自动化做到 95% 后放弃

她自己用 Cowork 做 Gmail 收件箱清零时也还未达到 100%，但方向明确："找到重复做的、不喜欢的事，交给 AI，打磨到完全可靠。省下来的时间，去做你真正想做的事。这才是 AI 给每个人的真正杠杆。"

对 Sentino 的应用：用 Kat 标准复审已用 AI 的工作流——是否任一流程做到了 100%？如果都停在 95%，那 5% 的"工作"等同于没自动化（因为人还得介入兜底）。

Linear Saarinen 视角的反例式补强："hard problems remain hard"

Linear CEO Karri Saarinen 在 2026-04-26 X 长文给 CREAO 95% 论 + Anthropic 100% 论加了一个不同细分赛道有不同自动化天花板的视角。Linear 自家数据：

"With just our own cloud coding agent, we are now fixing more than 1,000 issues per month and it's increasing fast. The biggest impact I see is increased bandwidth. We can tackle more smaller problems than before."

但他立刻给反例：

"But hard problems remain hard. Agentic coding does not speed those up as much as the narrative often suggests. It helps around the edges, with scaffolding, refactoring, investigation, and smaller fixes. But the difficult parts still require understanding the system, making tradeoffs, and knowing what should exist."

价值分配：

"In expert coding workflows, the value is usually not 'AI writes the code and you accept it.' The value is acceleration around the work. ... The expert still supplies the taste, constraints, and final judgment."

与 CREAO 95% / Anthropic 100% 的对照关系：

来源 自动化覆盖率主张 边界
CREAO 程凯 95% AI / 5% 人——AI-first 操作定义起步门槛 多数任务都可以达到 95%，关键是组织敢不敢做
Anthropic Kat Wu 100% 才是真自动化 95%→100% 那 5% 是"真正的工作"——必须坚持完成才算自动化
Linear Saarinen "hard problems remain hard" 任务本身分两类：smaller bandwidth 任务可达 100% 自动化 + hard problems 永远需要 expert judgment——这层不应被 95% / 100% 数字混为一谈

三者不冲突，覆盖三个维度：CREAO 是组织起步门槛、Anthropic 是单流程合格线、Linear Saarinen 是任务难度天花板。CREAO 的 99% 代码 AI 写适用于 Linear "smaller problems" 大量重复任务侧；Linear "hard problems" 侧 Saarinen 的判断是永远不会到 100%——这层不是 5% 努力问题，是任务本质。

对 Sentino 的应用：评估 AI-first 改造时要把任务先分两类—— - smaller bandwidth 任务（重复 bug 修、文档生成、reformat、CI 跟进）→ 直接套 CREAO 95% + Anthropic 100% 路径，把它做到底 - hard problems（架构选型、多客户取舍、产品 pivot 决策、合规风险判断）→ Saarinen 视角不要追求 AI 化，主动保留 expert judgment 通道

避免的具体陷阱：把 hard problems 也按 95% AI 化路径走，最后会发现 5% "兜底" 实际是 50% 实际工作量——因为 hard problems 不在被 95% 覆盖的"smaller problems"分布里。这是 expertise-paradox 的组织化表现——novice 评估"我们 AI 化进度"时容易把 hard problems 和 smaller problems 搅在一起报 95%。

工程师 PM 融合：Anthropic 头部组织样本

Kat Wu 给 research-preview-pattern 三个加速机制之一是"PM 和工程师角色在融合"——Anthropic 倾向于招聘有产品品味的工程师而非传统 PM。"几乎所有 PM 都有工程背景"。

"代码变得越来越便宜了。那什么变得更有价值呢？决定写什么。"

典型流程：工程师从看到社交媒体用户反馈开始 → 周末就自己上线功能，几乎不需 PM 参与。

与本页"架构师 vs 操作员"的关系： - CREAO 框架：架构师（六边形战士） + 操作员（其他人） - Anthropic 实践：工程师 + 产品品味在同一人身上 - 两者方向一致——都在重组"决定做什么 vs 能做什么"的传统分工 - 区别：CREAO 是新组织从头设计；Anthropic 是头部公司主动改造已有 PM 角色

对 Sentino 的具体含义：当前 Sentino 团队（Chris=CEO/子昕=产品/姜涛=技术）三层分离。如果向 Anthropic 模式靠拢，需要"产品和工程的紧密协作"（如子昕跟工程师每周工作 1-2 天直接做产品决策），不必从头重构组织——这是低成本高 ROI 的演进方向。

副作用警示：Kat 承认融合带来产品一致性问题——同一需求会有两个功能在做。Anthropic 的取舍是接受这个代价（提供 /powerup 教程让用户挑），不为消除冗余而放慢。Sentino 客户量未起量阶段，功能爆炸 + 内部对齐损耗比 Anthropic 千人级更难承受，需要在引入"工程师 PM 融合"时加内部对齐机制（如周会快速过一遍所有 in-flight 功能）。

自检命题

如果你自己的公司都做不到 AI first，你凭什么做出一个帮别人 AI first 的产品？

程凯给所有 AI 创业的核心建议。这是一道销售可信度的根基题——不只是"产品够不够好"，是"你卖给客户的承诺自己有没有兑现"。

对 sentino 的应用： - Sentino 给 sentino-tenga 卖"AI 化 Seicil 性教育 Q&A" → Sentino 自己的产品/QA/合规流程是否 AI 化？ - Sentino 给 yukai-agora-poc 卖"AI Agent 适配陪伴机器人" → Sentino 自己的客户支持/PRD 评审/项目管理是否 AI 化？ - Sentino 给 hotmind-client 卖"完整 Agent 工程能力" → Sentino 自己的 Agent 平台开发流程是否 AI-first？

每一个答案不是 yes 都是销售时的隐性短板。

平台 Harness 的两层定义

CREAO Peter 在 Founder Park 访谈中给 Harness 加了一个分层：

层 谁负责 内容 代表
第一层（用户层） 用户 怎么 harness 自己的 agent——配置和定制 Anthropic Skill 系统 / OpenClaw / Cowork / 开源 agent 框架
第二层（平台层） 平台方 怎么 harness 整个开发 agent 的系统——基础设施 CREAO 自建 / Claude Code 后端

很多公司停留在第一层——把 Harness 能力开放给用户去自定义。CREAO 主张第二层才是核心：

iOS vs Android 类比

"做到最后就是对整个硬件系统的掌控（GPU / 推理速度优化）——封闭系统才有的优势。"

对 sentino-agent 的应用：Sentino Standalone Agent 当前的"用户填 prompt + 选工具 + 设触发条件"形态属于第一层 Harness。如果要上规模和可靠性，需要把 Standalone Agent 运行环境（sandbox / 工具版本 / memory / cache）都封闭定义——但这与 agent-tool-design "逃生工具"原则矛盾，需要权衡。

"环境稳定 > 智商高"核心论断

CREAO 给 Harness 价值的定量描述：

环境的稳定、基础设施的能力，基本上就可以把 AI 能力从 50 分提到 90 分。剩下那 10 分才是真正有追求的人才需要去做的事。

含义： - 当前阶段大多数 AI 产品的瓶颈不是模型不够智商，是环境（sandbox / 工具 / memory / 并发隔离）不稳定 - 大多数普通人工作不复杂——基于文档的高阶操作（总结 / 分类 / 打标 / 可视化，几乎就这四种类型）。这种任务对模型智商要求不高，对环境稳定性要求极高 - 商业化的甜蜜区已被收窄——基本上是短暂但高频发生的重复性任务，需要稳定环境而非复杂智能 - 真正需要长时间执行的单一任务很少，更多是长时间的多次工作（投资人大汇报 = 拆解很多小任务）

"今天有多少人完全利用到了大模型所有的智商？很少。"

这条对 harness-engineering "Agent = Model × Harness" 的乘法关系给出了具体的分量分配——当前阶段 Harness 占 50→90 那 40 分。

不做 Marketplace 的判断

CREAO 明确不做 agent marketplace，理由值得记录（同一时期 sentino-agent Standalone Agent SaaS 形态分层设计可参考）：

对 sentino-agent Standalone Agent SaaS 分层（个人/团队/Enterprise）的直接启示：分层重点应该放在"协作模式（共享 agent / context 给同事）"而不是"交易市场（卖 agent 给陌生人）"。后者会撞上"工作流个性化导致 agent 不可移植"的根本问题。

Skill vs Agent 的区别

CREAO Peter 给 Anthropic Skill 系统和自家 Agent 一个清晰的区分：

Skill = Agent 的 Runbook
    └── 一个文档文件让 Agent 从基础设施层面正常运行
    └── 是更底层一层设计

Agent = Skill + Memory + Widget + Schedule
    └── Skill 之上还有 Memory（跨会话）
    └── Widget（展示层）
    └── Schedule（调度机制：怎么触发、怎么定期运行）
    └── 用户能定期 rerun 复现结果

CREAO 在构建 Agent 时已帮用户生成 Skill——用户不需要先学 Skill 概念。Skill 之上还构建很多其他东西。

对 agent-tool-design / agent-runtime-architecture 的直接补充：Skill 不是终极抽象，Agent 比 Skill 多三层（Memory / Widget / Schedule）。Agent runtime 架构七层模型中 Skill 在 Layer 7（扩展层），但 Agent 还需要 Layer 3（Memory 预取）+ Layer 6（Task 调度）+ UI 层。

三层 Memory 管理机制

CREAO 内部 memory 系统的具体三层（与 agent-runtime-architecture Layer 3 + auto-memory / auto-dream 同源）：

  1. Thread 内：Context 接近模型 Context Window 上限时压缩 → 模型对 Thread 总结 → 应该记住的存到文件系统
  2. 跨 Thread：每次用户请求结束后独立服务用模型判断有无值得长期记录内容（用户决定 / 个人信息）→ 存储 + 与之前 Memory 去重
  3. 新 Thread 启动：把和当前用户请求最相关的前 15 条历史 Memory 提前加载到上下文

关键设计点： - 跨 Thread 提取走独立服务（不阻塞主流程）——这是 harness-engineering "Side Query" 原则的具体应用 - 新 Thread 加载 top-15 是 sentino-memex "<500 active gists 时全量返回"思路的另一极——CREAO 用 top-N 排序裁剪 - 与 auto-dream 整合 / auto-memory 写入边界互补——CREAO 的三层覆盖了"压缩 / 提取 / 注入"完整生命周期

Coding Agent 是基础设施判断

Peter 在访谈中给 Coding Agent 一个概念厘清——它不只是"写代码"：

能力维度 含义
写代码 表面能力
文件系统访问 能持久化中间结果
Memory 管理 跨任务/跨会话保留状态
工具调用 通过 function calling 接外部能力
API 调用 接 SaaS / 数据源
长时间稳定运行 不崩 / 不漂 / 可恢复

写代码能力让 agent 通用，是因为大部分任务遇到边界情况需要 agent 自己现写代码：

Amplitude 现写代码案例

用户拿最新 10 封邮件可以调 connector，但拿到后定制化处理就是边界情况——以前需要平台方提前做好 connector，Coding Agent 现写代码现编译现运行直接交付。

CREAO 内部具体执行：原本需要自己开发 Amplitude connector 提供授权接口；现在用户跟 agent 描述需求 → agent 一步步写出连接代码 → 告诉用户登录 Amplitude 给 TOKEN → 直接 access 所有数据。

"用户所有基础工具的连接现在都可以实时完成，不再依赖平台方提前把所有 connector 做好。"

对 agent-tool-design 的直接含义：传统工具集设计是"平台预备 connector 集合"，Coding Agent 把这件事颠覆——Coding Agent 是 connector 的元工具，覆盖长尾问题的能力比"调接口"宽得多。这是 mcp-protocol 的反向：MCP 是"先定协议"，Coding Agent 是"现场写"。

Marketing 抓取案例

CREAO marketing 同事每天生成竞品分析报告 → 每个网站结构不一样不可能预备 parser → Coding Agent 现场写抓取代码 + 遇阻自调整 → 跑通后变成 rerun agent 每天自动跑。

对 sentino-agent Standalone Agent 工具集设计的启示：Sentino 当前 Standalone Agent 的工具集是平台预定义的（read_xx / 调 API）。如果引入 Coding Agent 能力（让 agent 自己写抓取/解析代码），可以大幅扩展长尾覆盖——但需要 sandbox 隔离 + 安全审计配套。

Sandbox 隔离与启动时间优化

每一个用户请求启动独立 sandbox 环境（与 agent-runtime-architecture Layer 5 Permission 执行隔离对应）：

早期直接用 claude-agent-sdk / Claude Code 但启动时间 10-20s 不可接受，CREAO 自建架构深度优化到 <5 秒。

"这件事只有充分了解自己整套架构才能做到——OpenClaw 这种开源框架要面向各种环境无法对特定场景做性能优化。"

Agent 之间运行环境必须隔离，否则 A agent 装 3 个工具包 B agent 启动时改其中一个属性 = A 工具不稳定 → 无限调优循环。

对 Sentino 的启示：与 sentino-agent 评估 Claude Agent SDK 后选择自建 Agent Loop 同向同源——CREAO 也是评估后选择自建以追求性能。这条事实给 Sentino 自建决策加了一个同向证据点：行业头部 AI 创业（CREAO + Sentino）都在评估 Claude Code 后选择自建轻量实现。

未解张力

25 人公司的经验能推广到 500 人组织吗？ CREAO 的转型发生在小团队、创始人主导、无历史包袱的环境中。大组织面对的阻力维度完全不同：合规审计、跨部门政治、遗留系统迁移、工会谈判。"一个架构师 + Agent = 100 人"在绿地项目成立，但棕地迁移的成本可能吃掉全部效率增益。

"人类审查 AI 的 PR"是否可持续？ 当 AI 写 99% 代码时，人类审查者面临与 L3 自动驾驶相同的困境——系统运行良好时注意力衰退，恰好在需要人类介入时失去判断力。CREAO 用三通道 AI 审查缓解这个问题，但审查 AI 审查结果仍需要人类，递归没有终止。

CTO 每天 9AM-3AM 是否是系统设计的失败？ 如果系统需要一个人持续 18 小时维护才能运转，那系统本身可能还没有真正"自愈"。这与"一人公司"的愿景矛盾——一人公司的前提是系统自治，不是一个人做所有人的活。

相关概念