摘要

真正的 AI-first 是把生产力主导权从人交给 AI，并围绕它重写流程、权限和组织，而不是给每个岗位增加一个 AI 工具。 陈凯称，人继续充当工具使用者，效率提升“可能最多就十倍”；若想达到一百倍、一千倍，AI 得主导 planning、execution 和跨团队对齐，人则负责提供信号、架构系统与审核结果。对投资者而言，分水岭不在 AI 使用率，而在公司能否把“信任人”迁移成由 guardrails 和机制支撑的“信任 AI”。
Harness engineering 把竞争层级从模型和 prompt 提升到了能持续运行、自我修复、自我提升的完整系统。 它涵盖 context、tooling、sandbox 与 host 的交互、安全、启动时间、latency、testing 和反馈闭环；工作时间越长、工具越多，越容易出现 hallucination、context overflow 和能力 degradation。Peter 的非共识是：“这个系统怎么能够从一个静态的状态真的活起来”，而且迭代应由 AI、不是人来主导。
Creo 给出的内部效率基准是：过去约需一百人、四五个月开发的产品，如今由不到十名工程师约两周完成首版 deployment。 泓君复述 Peter 的帖子称，这家约二十五人的公司有 99% 的代码由 AI 编写，上午 10 点提出功能、中午 A/B test、下午 3 点裁掉无效部分、5 点重写版本，传统周期约为六周；帖子获得约 187 万浏览。这里可交易的变化不是单纯少雇人，而是迭代速度令产品路线本身从稀缺品变成库存。
AI coding 能否规模化，取决于质量闭环能否把 bug 从“人肉救火”变成自动发现、分级和修复。 Creo 的 agent-driven CI/CD 与 bug triage 可在一两分钟发现问题、数秒完成分派，并在一两个小时内调查、修复和重新上线，过去可能需要一周；目前 50% 以上 issue 据称通过 auto fixing 处理，低风险修改只需工程师简单 approve。安全、agent behavior 等敏感改动仍由专人深度 review，说明人的稀缺价值正在向架构和高风险判断集中。
当开发速度超过市场吸收速度，公司的瓶颈会从 engineering 转向 go to market、需求判断和 evaluation。 Creo 形容技术团队已领先 marketing 三到四个月，甚至四到五个月，市场需要苹果就从“菜篮子”里拿苹果，需要香蕉就拿香蕉；但文章、视频和营销素材缺乏代码那样明确的正确性指标，目前仍是“放很多 agent 的结果，再由人判断”。投资含义是，代码供给爆炸后，市场需求判断、内容评价及反馈数据链可能成为新的约束。
开发成本下降正在重估产品经理、工程师和设计师，而不是简单消灭其中一个岗位。 Creo 把产品经理职能拆到工程师和工程管理者身上，未来更可能由团队共同承担；Peter 判断，真正稀缺的是能在一两个小时内把 idea 直接带进产品的复合型人才，因为一旦需要转交，“alignment 的成本就远大于 implementation 的成本”。拥抱 AI 的资深工程师仍不可替代，但公司可能只需要一两位，而不再需要原来的十倍甚至五十倍人数。
Agent 既可能成为软件的操作者，也可能成为内容、广告和采购信息的第一层消费者。 团队选择 task management 产品时，关注点正从人看的 dashboard 转向 agent 可用的 MCP 和 API；Clark 自己采购 SOC 2、ISO 合规服务时，也先让 agent research 和筛选。Creo 因而主张从所有人共享一个 general agent，转向每家公司拥有持续 self-healing、self-improvement 的专属 agent，首要客户是约三十人以内、legacy 与合规负担较轻的 SMB。
嘉宾对长期结果整体乐观，但对迁移过程保持明确保留。 人的核心价值被归纳为定义需求、架构系统、判断“这件事是否还有价值”并审核最终结果；Peter 同时强调，即使在当前阶段，AI 也不能取代人做任何事情。真正的风险位于转型期：组织不愿交出控制权、权限和隐私边界仍待建立或完善、资深人才的旧 specialty 被重估，以及大量岗位需要在痛苦与 noise 中重新定义。

精读

1. Harness 把模型优化扩成了整套动态系统

Peter 将三阶段区分得很清楚：prompt engineering 优化提示词，context engineering 补足上下文，两者主要处理人与 LLM 的交互；harness engineering 的 scope 则覆盖围绕模型的基础设施。
相较于针对一个 vertical task 的静态优化，harness 要处理 general system：tooling 如何接入、sandbox 与 host 如何安全交互、sandbox 启动多久、latency 多高，以及系统出错后如何恢复。
泓君把它概括为“怎么把一个大模型炸出它的最佳使用上限”。她举出的反差是：一个 agent 一夜完成三个人的 SEO 工作，另一条 content pipeline 连跑两天才被发现“全是垃圾”；差别不只在模型，而在外围系统能否持续校正。

2. 真正的非共识是让系统自己“活起来”

Peter 认为市场对 harness 的常见理解仍然静态：开发一套约束和工具，把 LLM 的能力发挥得更好；Creo 的定义则是，“这个系统怎么能够从一个静态的状态真的活起来”。
动态 harness 要持续接收 marketing、产品、用户和 infrastructure signal，再让 AI 主导迭代。人的任务不是逐项修改结果，而是“把各种各样的 signal feed 给 AI”。
Agent 也不是 one shot 创建后就算完成；用户如何 follow up、系统如何根据结果 self-healing 和 self-improvement，才决定它能否长期承担真实工作。
Peter 把长任务视为 inference 阶段的 scaling：提供更多 context、更多 tooling 和更长思考时间。代价是 hallucination、context overflow 与模型能力 degradation 的概率一同上升，因此 harness 本身成为复杂工程。

3. AI-first 不是给旧流程装上 Copilot

陈凯的核心判断是：“并不是在现有的流程上面去使用 AI 的工具，而是要围绕 AI 的能力去重新构建你的工作流程和组织形态。”
Creo 曾经让工程师用 AI 写代码、产品经理用 AI 写 PRD、设计师用 AI 作图，结果整体效率并未明显提高。每个人的速度被分别加快后，remote 团队节奏更加不同，alignment 成本反而上升。
陈凯给出的上限判断很激进：只要人仍是工具使用者，提升“可能最多就十倍”；要提升一百倍、一千倍，“AI 应该是所有生产力的主导”，人从实际工作者转向结果 review、系统协作与价值判断。

4. 组织转型首先改的是信任，而不是代码

Peter 认为推进 AI-first 最先遇到的是人的问题：团队能否接受新的工作方式。过去可能需要数月证明新 architecture 更好，AI 辅助后可在一两周内重构前端、后端、infrastructure，并用 deployment 频率、可靠性和最终效果说服团队。
陈凯把组织摩擦归因于信任不足。过去 GTM 与 engineering 必须沟通、达成共识再推进；现在 AI 可以直接把即将发布的功能和结构同步给 marketing，减少人际对齐环节。
泓君追问得很具体：AI 怎么知道 engineering 明天真能做完？Peter 的回答不是让 AI 猜排期，而是降低对详细排期的依赖，把关注点转向 feature 是否改善 top-line metrics、是否产生真实使用数据。
数据链一旦搭好，agent 就能依据上线表现判断 feature 是否有用，以及是否要 rule out 或 fallback。换言之，对齐依据从人的承诺变成可反馈给系统的运行信号。

5. AI-driven CI/CD 把质量控制改造成闭环

Peter 不否认 AI coding 会产生 bug：“不管是 AI 写代码还是人写的代码都会产生 bug。”Harness 的目标不是获得一个永不出错的静态系统，而是持续发现并提升系统。
第一道防线是 integration 与 regression test，避免明显问题进入 production。传统 CI/CD 多由 rule 和 unit testing 驱动，Creo 则加入 AI-driven integration、unit 与 end-to-end testing，Peter 以 Playwright 为例说明全链路检查。
第二道防线发生在上线后：系统监控 log、error 和 incident，把 signal 反馈给 AI，判断代码质量并识别 corner case 或 risk condition，再触发 bug triage。
多个 agent 可以并行负责前端、后端和 agent 核心系统。Peter 给出的周期是：一两分钟发现 bug、几秒钟 assign，工程师再用 agent investigation 和提出 solution，总计一两个小时；传统流程可能要一周。

6. 自动修复提高了速度，但没有消灭架构师

Creo 过去同时维护 feature wish list 和 bug list，市场、产品、工程不断争论先做功能还是修问题。如今团队称两张 list 都消失了：bug 被及时修复，feature 供给又远超当前需要。
Auto fixing 会按代码目录的风险分级；低风险文件中的问题由 AI 自动提交 PR，工程师简单 approve 后即可进入 production。目前“百分之五十以上的 issue”以这种方式处理。
若修改触及安全或 agent behavior，仍需对应人员 deeper review。Peter 所说的 behavior 不只指输出内容，还包括 cost、latency、hallucination、tool authentication，以及任何会让用户 task 无法完成的系统交互。
面对泓君“工程师是否还得重新读懂整套代码”的追问，Peter 将工程团队分为 architect 与 operator：AI 能给 solution，但安全、latency、sandbox-host 边界仍由 architect 决定。过去搭系统可能需 10—20 人，如今一个 architect 或可在一周内完成整个系统的搭建。

7. 出错时应修系统，不应只纠正一次输出

陈凯要求把 AI “当成一个系统来看待，不要把它当成一个智能来看待”。错误发生时，与其纠正这一次智能输出，不如寻找系统的漏洞。
他也反对把 harness 理解为“静态的固定的枷锁”；更贴切的比喻是养孩子，在规则内让它不断成长。平台提供的不是一次答案，而像一个“培训师”，告诉用户发现错误后如何让 agent 以后做得更好。
泓君以改稿为例：一个大错误可能迫使编辑重读全文，成本接近重写。陈凯的回答是，应优先问系统为什么允许这类错误出现，而不是把全部精力花在修补单点。
他的进一步反问更激进：人眼里的错误是否仍是最终消费者眼里的错误？“重新思考这个问题，它是否还是一个问题”，需要先确认未来究竟是谁在消费结果。

8. Agent 可能成为内容和软件的首层消费者

陈凯设想，文章、图片和视频未来可能首先由 agent 消费；某个营销 asset 不符合人的审美，却可能在 agent 读取或筛选时产生更好的数据反馈。Harness 因而必须围绕真实消费者的偏好优化。
泓君对此提出保留：agent 购买和阅读并不意外，但她没想到现阶段已经来得这么快。Clark 给出亲身例子——寻找 SOC 2、ISO 合规服务时，他先让 agent research 和筛选，自己再查看候选结果；未来第二、第三层判断也可能继续被接管。
Peter 从 SaaS 交互看到同一趋势：Asana、Linear 等 task management 产品过去围绕人看的 dashboard 构建，现在团队更关心 agent 能否读取、排序和处理 task，因此 MCP、API 的质量比过去更受关注。

9. 市场的障碍往往是不知道新工作方式存在

Peter 判断，大部分 agent 公司的主要 challenge 不是用户拒绝这种方式，而是“市场不知道这种工作方式的存在”，也不知道怎样让 agent 高效完成工作。
Creo 因此试图降低复杂设置：普通用户不必理解 sandbox、tooling、安全和长时间运行的 infrastructure，只需理解自己的任务，底层 harness 由云端 service 提供。
这也回应了“每个垂直领域都需要专家”的质疑。平台并不声称掌握所有行业知识，而是把架构、安全、工具连接和维护 agent 的通用难题封装起来；领域判断仍属于用户。

10. Creo 的转型经历了从辅助人到 AI 主导的转折

陈凯回顾，2025 年上半年公司仍认为 AI 是辅助工具，人占主导；到下半年，他们发现效率远低于预期，核心原因是“生产力工具的使用者”没有真正从人切换成 AI。
这不是一天完成的。Marketing 与 engineering 曾用一两个月反复讨论新的协作方式；团队约在 2025 年 8—9 月意识到必须重构，先做 mindset alignment，到 2026 年 1 月、春节前才正式动代码和流程。
Peter 补充，转型也受模型能力约束：基础模型、agent architecture 和 infrastructure 都在一年内跃升。一年前若要求 AI 主导开发，“从技术上来说是不成立的”，到重构时才同时具备速度和效果条件。
实际重构用了约两周，覆盖前端、后端、architecture 和 infrastructure；节目中所见产品也来自这次重建，而非在旧系统上继续叠加 AI 功能。

11. Planning 从不及格跃升到九十分，人的工作变成挑错

Peter 用打分说明能力变化：一年前 AI 的 planning 约为 50 分，需要人直接修改 plan 和 architecture；现在初稿可到 90 分，人只需 criticize，再让它自行 revised。
新架构中，他称自己“一行 code 也没有写，一行的 text 也没有去改这个 plan”。交互方式是追问 security、latency 和 architecture 缺陷，要求参考流行 open-source agent framework，再生成最终版本。
当泓君问 AI 的能力是否已在他之上，Peter 明确区分：AI coding 肯定强于现在的他——“2026 年我就没有写过一行代码”；但 architect 的价值仍是发现 planning 中的安全和 latency 缺陷。
一次纠偏还能沉淀为 skill。例如 sandbox 与 host 的安全原则被写进 skill，下一次团队成员只需要求 AI follow 这套 principle，不必重新解释具体规则；这正是经验从个人记忆转成组织 harness 的过程。

12. 研发效率跃升后，产品供给反而领先市场数月

Peter 估算，若回到一年前的非 AI 主导方式，开发当前 Creo 产品至少需要约一百人的团队、四五个月；现在公司共约二十五人，工程团队不到十人，首阶段 deployment 约两周。
泓君复述 Peter 获得约 187 万浏览的帖子：上午 10 点写功能，中午进行 A/B test，下午 3 点依据数据砍掉一部分，5 点重写更好版本；传统开发节奏可能要六周。文章同时称 99% 的代码由 AI 编写。
软件时代通常是销售概念领先产品四五个月；Creo 观察到方向已经倒转，engineering 领先 marketing 三到四个月，甚至四到五个月，做完许多市场团队尚不知道的功能。公司运营不再围绕稀缺 roadmap，而围绕哪些能力值得推向市场。

13. Go to market 成为更难自动评价的新瓶颈

Clark 用“菜篮子”和“机器猫的万能宝箱”描述新状态：市场今天需要苹果，就从既有产品库拿苹果；明天需要香蕉，也无需等研发重排 roadmap。
但 GTM 比 coding 更难 harness。代码有相对封闭的 evaluation 和明确通过标准，文章、视频、图片面对不同人或 agent，价值判断更主观；如何把这些判断转成系统可使用的 signal，仍是最大挑战之一。
Clark 的诚实边界是，公司尚未“百分之百让 agent 去做决策”。现阶段会生成很多 agent 结果，再由人判断好坏；即使内部已有大量 feature，只要认为市场没 ready，就不会直接推出。
较超前的内部实践是让 agent 拥有广泛读写权限。过去 Clark 查询某类用户行为，要找数据或工程同事搭表；现在 agent 约三秒给出答案。但若读错数据或“自己开始乱搞”，决策会被污染，因此权限控制仍未 ready 面向市场。

14. 专属 Agent 与组织重构构成 Creo 的产品赌注

Peter 将上一代 general agent 或 super agent 概括为：平台提供一个 unique agent，所有用户访问同一个助手。Creo 想让用户创建属于自己的 agent，并让它理解特定 workflow、持续 self-improvement 与 self-healing。
他的例子是 weekly campaign：用户不必每周重新指挥 general agent，而是建立一个 campaign agent；平台在背后 harness 它的 performance、cost 和产出，使流程越跑越稳定。
目标客户主要是 SMB，陈凯具体描述为可能约三十人以内的中小团队。科技公司和传统公司都可转型，关键不在人少，而在 compliance、legacy database 与既有流程负担是否足够轻。
对客户而言，入口不是立刻照搬 Creo 的组织结构，而是先使用被产品化的 harness，再逐步思考组织改变。陈凯提醒，若创始人不能接受数据库、交互和产品 architecture 的整体重构，仅在旧 SaaS 中增加 AI feature，很难完成真正转型。

15. 岗位边界消失后，价值集中到架构、实现与判断

Creo 的第一个组织变化是信任对象：过去组织信任人，现在要靠 guardrails 和机制，让 AI 的 planning、decision 与 execution 都达到可被人信任的程度。
产品经理职能没有简单消失，而是拆到工程师和工程管理者身上。陈凯认为 PM 往往是市场与研发矛盾最集中的节点；不再设置单独的产品经理角色后，若系统仍能维持信任，对齐成本反而会下降。未来也可能由整个团队“扮演产品经理”。
Peter 看到的主线是复合型人才上升：工程师需要 product、marketing sense，产品经理和 UX/UI designer 需要 implementation 能力。Idea 若能在一两个小时进入产品最有价值；若必须传给另一位工程师，“alignment 的成本就远大于 implementation 的成本”。
Junior engineer 往往更容易扩大 scope，从写代码延伸到设计、上线后分析和 impact 判断；资深工程师则可能受十年、二十年 specialty 的影响。但 Peter 没有判定 senior 可替代：最稀缺的仍是拥抱 AI、又有架构和产品判断的资深人才，只是公司可能仅需一两位，而非过去多出十倍甚至五十倍的人。

16. 人最终保留的是定义价值和审核结果的权力

Peter 将未来人的核心能力概括为系统架构：从 implement feature 转向 architecture、maintain AI system；这不仅适用于工程，GTM 也要构建能自主运行的 marketing system，而非手工生产单条内容。
陈凯认为，只要技术仍服务于人，人就负责定义需求方向，并审核结果是否符合自身利益；Clark 进一步压缩为一句话：“人未来的价值就是判断任何事情是否还有价值。”
这套判断仍有明确边界。Peter 明确说，即使在当前阶段，AI 也不能取代人做任何事情；但它已经能够主导很多事情，系统能否稳定运转仍需人架构。Agent 与其他 agent 或人沟通后，谁能查看内容、是否侵犯隐私，也会催生新的道德问题。
三人的情绪都偏乐观但程度不同：陈凯认为 AI 可能帮助更好地切割工作与生活；Peter 从创业角度乐观，以工业革命类比岗位被取代后人会找到新的方向；Clark 则“非常谨慎地乐观”，承认变革中会有痛苦和 noise，但相信最终会释放更多时间和人的潜能。

74.与地瓜、阿里云的访谈：机器人爆发前夜，工程师成长，与 AI 的第三朵云所有算力都是食物：Palisade 的 Jeffrey Ladish 谈 AI 抵抗关机、自我复制与生态