我一直在初创企业工作。我的角色通常是这样的：在一片混乱时加入，打好基础，解决难题，让系统不再那么脆弱，然后维持这个状态。
但在本职工作之外，我真正热衷的，始终是做出有意思的产品。
越积越多的点子
注意缺陷多动障碍（ADHD）让整个过程带上了一种特殊的节奏。我的问题不是想不出点子。真是那样，反倒省事了。我的点子太多、来得太快，而且细节足够丰富，让每个点子都能短暂地显得非做不可。
我的大脑擅长最初的 30%。它能看见规律、切入点、系统、缺失的工具、糟糕的抽象、更好的抽象，有时甚至能看见那个应该存在于更好抽象之下的工具。
点子 1 ─┐
点子 2 ─┤
点子 3 ─┼──> 都有道理
点子 4 ─┤ │
点子 5 ─┘ ↓
周末原型
│
↓
旁边更有趣的问题
烦人的是，这些点子往往并不差。要是明显不靠谱，我关掉标签页就能继续做别的。但它们通常说得通，有时甚至挺好。好到值得投入一个周末，再做出一个原型。
但很快，我的大脑就会在最初的问题旁边，发现一个更有趣的问题。
反复经历这个过程之后，我认定真正的问题不在某个具体的创业点子上。我需要一个系统，替我评估这堆点子：研究市场、估算执行难度、比较影响、收入潜力、分发渠道、竞争，以及其他所有我知道自己应该做的分析。
第一条逃生通道
于是，我开始做 CEOgenerator。
CEOgenerator 的目标，是在我对某个创业点子投入感情之前，先做一轮筛选。它不是要靠魔法找到产品与市场的契合点，而是让初步判断少一些冲动：收集证据、比较机会，确定哪些假设值得放到现实中检验。
说得更诚实一点，它应该保护我，让我免受自己的冲动影响，同时又不剥夺我想点子的自由。
太多创业点子
│
↓
CEOgenerator
│
↓
市场研究
执行难度
影响
收入潜力
分发渠道
紧迫性
竞争
│
↓
“哪个点子真的值得做？”
既然在脑子里已经想通了，我的下一个发现就是：我需要一个应用工厂，替我把这些东西做出来。
我一直把这叫作懒，但这只说对了一半。更强烈的驱动力是放大投入的价值：如果能把重复工作变成一个系统，我就能更快推进，不必每次都拖着自己的注意力走过同样的准备步骤。
于是，我又向下走了一层。
CEOgenerator 回答：
“我该做什么？”
│
↓
新问题：
“谁来做？”
│
↓
应用工厂 / 执行系统
绕向控制平面（Framepath）
我开始构建一个自己称作 AI 工作负载控制平面的东西。这个项目就是 Framepath。
想法是更可靠地协调 AI 工作：有治理约束的智能体、任务、脚本、产出物、审核步骤，等等。我想要的是一个可以检查的系统，把 AI 执行当作真正的工作，而不是一串寄托着希望的消息。
没有管理的 AI 工作：
提示 → 输出 → 希望有用
提示 → 输出 → 希望有用
提示 → 输出 → 希望有用
有控制平面的 AI 工作：
任务
│
↓
脚本 / 模型调用
│
↓
产出物
│
↓
审核步骤
│
↓
下一个有明确边界的动作
大约一个月里，这条路看起来都是对的，至少不像明显的分心。这正是绕路的问题所在：每一步通常都有理由。每一层抽象都在解决上一层的真实局限。
然后，我开始考虑发布它。
公开发布需要产品定位、文档、示例、增长实验、内容，也许还需要社区和开发者关系。
Framepath（控制平面）
│
↓
需要发布
│
├──> 产品定位
├──> 文档
├──> 示例
├──> 增长实验
├──> 内容
├──> 社区
├──> 开发者关系
│
↓
“这些手动工作也太多了”
这已经不只是产品工程，而是围绕产品开展的公司运营：解释它、分发它、证明它、支持它，以及在产品本身还不断变化时，让对外叙述保持一致。
放大工作效率的本能再次启动。下一个结论出现了：我需要智能体，帮我运营围绕这个产品的公司。
一层又一层的治理
这让我找到了 Paperclip。
我尝试通过 Paperclip，让智能体执行公司的运营工作：研究、规划、内容、跟进、审核，以及围绕产品反复发生的日常事务。这正是我需要的。问题在于，不受约束的智能体会自己创造工作。它们会做事，有些有用，有些看似合理却是错的，还有些在狭义上已经完成，在大局上却毫无价值。
于是，我开始在 Paperclip 之上构建一个治理层。
这个治理层负责定义角色、结果、审核关卡、工单模板、审批节点，以及正确的任务配置。我不想让智能体四处游走、卖弄聪明。我希望它们在工作流内行动，产出人类可以审核的结果。
Paperclip 智能体
│
↓
治理层
│
├──> 角色
├──> 结果
├──> 审核关卡
├──> 工单模板
├──> 审批节点
├──> 任务配置
│
↓
有明确边界的工作
│
↓
可审核的产出物
这同样合理。如果智能体要做真正的工作，治理就很重要。
但接着，另一个问题浮现出来：专门为 Paperclip 做这套东西，似乎限制太大。真正有用的想法更通用。它应该成为 Paxlings：一个受 Paperclip 启发、扩展性更强、也更适合普通用户使用的 AI 工作者平台。
Framepath 这个 AI 控制平面，是协调工作的基础设施。Paxlings 这个 AI 工作者平台，则是产品化后的形态：可复用的工作者、封装好的工作流，让其他人不必理解底层机制，也能运行这些工作。这个方向受到了 aiworkers.so 的启发。
于是，我开始朝这个方向走。到这时，循环已经完全运转起来了。
起初，我只是创业点子太多。我做了一个系统来决定该做哪个，然后把它放到一边，开始构建 Framepath 这个运行 AI 工作的控制平面。接着，我发现需要智能体帮忙发布 Framepath，于是给 Paperclip 智能体添加治理；再后来，我发现治理应该可以迁移，就开始把它变成 Paxlings。
写出来，听上去简直疯了。身处其中时，它却是一连串合理的决定。
点子太多
│
↓
CEOgenerator
│
↓
需要执行
│
↓
Framepath（控制平面）
│
↓
需要发布支持
│
↓
Paperclip / 公司智能体
│
↓
智能体需要治理
│
↓
可迁移的治理
│
↓
Paxlings（AI 工作者）
Markdown 这一层（Build Right）
某个时刻，我意识到，自己其实不想一步一步看着智能体做事。我想要的是有真正执行框架支撑的快速工作循环：定义结果，让模型或智能体执行一个有明确边界的流程，产出正确的结果，在合适的时刻停下来，由我审核。
于是，我开始把自己工作中反复出现的部分，提炼成代码仓库里的技能文件和脚本。这就是 Build Right。
Build Right 来自旧项目模板、脚手架、与智能体的交互，以及我手动执行过太多次的创业工作流：点子筛选、市场研究、产品需求、GitHub 工单拆解、验收标准、发布计划、人工审核清单、批评与改进循环。
旧项目模板 ─┐
脚手架 ─────┤
智能体交互 ─┼──> Build Right 技能
创业工作流 ─┤
手动流程 ───┘
Build Right 技能：
点子筛选
市场研究
产品需求
GitHub 工单拆解
验收标准
发布计划
人工审核清单
批评与改进循环
等等
接着，荒诞的部分变得清楚了：Build Right 技能，几乎就是此前我构建的每一层中真正有用的部分。
它们具备我想从 CEOgenerator 获得的部分能力，却不必先把 CEOgenerator 做成完整产品。它们体现了 Framepath 控制平面的思路，却没有那份复杂性。它们提供了我想为智能体设置的治理，又不把我绑在 Paperclip 上。它们具备我想从 Paxlings 获得的实际价值，却不要求我先搭好整个平台。而这些东西，大部分只是 Markdown。
折腾完所有架构，我最后落在了指令上。不是“扮演一位资深产品经理”这种含糊的提示，再盼着结果不错。Build Right 是一组 Markdown 仓库技能文件，写明工作流、输入、输出、约束、审核节点和完成标准。它把实际工作中的判断写成小块内容，清楚到有能力的模型能遵循，人类也能检查。
一个好的 Build Right 技能，能把模糊的产品想法变成范围明确的任务、验收标准、验证计划和审核节点。这不是一家公司，也不是一个平台。但它已经能给下一项工作足够清晰的结构，让它真正发生。
这个闭环，完整得近乎刻意。
我在构建 Build Right 技能，它们可以帮助构建 Paxlings；Paxlings 可以帮助发布 Framepath；Framepath 可以帮助构建 CEOgenerator；CEOgenerator 可以帮助我决定做什么；然后，我又可以用同一套技能把它做出来。
┌────────────────────────┐
↓ │
Build Right 技能 │
│ │
↓ │
Paxlings（AI 工作者） │
│ │
↓ │
Framepath（控制平面） │
│ │
↓ │
CEOgenerator │
│ │
↓ │
决定做什么 │
│ │
↓ │
把它做出来 ─────────────────────┘
到了某个时刻，架构图就变成了一份自白。
产品原来就是执行框架
最容易得出的总结，是我把一切都搞复杂了。这有一部分是真的。但更有用的结论是：我一直在错误的层次寻找产品。我首先需要的，不是围绕模型搭建一个更好的平台，而是围绕工作建立一个更好的执行框架。
如今的大语言模型，只要用法正确，已经能胜任数量惊人的产品工程工作。它们并不完美，也不能省去审核，但只要指令写得好，它们已经足够善于遵循。
它们如何配合
更清楚的分工是：Build Right 是智能体的工作规范，Framepath 是代码仓库内的控制平面，Paxlings 是客户使用的产品。Build Right 告诉智能体如何工作：厘清请求，区分证据与假设，制订计划，执行一个边界明确的任务，然后验证。Framepath 为这些工作提供受控环境：仓库状态、策略、适配器、验证、产出物和执行轨迹。Paxlings 则面向客户：用于业务工作流、有明确边界的 AI 工作者，配备审批、对外部影响的控制，以及可审计性。
这就是为什么这些项目总让人觉得相互关联，却又不是同一个东西。它们都在应对同一种失败：模型说完成了，AI 工作看起来也完成了，但实际上没有明确的目标、授权、验证或证据。Build Right 在方法层解决它。Framepath 在控制平面层解决它。Paxlings 在产品层应用这些原则。
把它们合并成一个东西，才会是错误。Build Right 可以帮助构建 Paxlings，却不必变成 Paxlings。Framepath 可以治理仓库内的工作，却不必成为 SaaS 产品。Paxlings 可以采用同样的原则，却不必成为通用智能体框架。贯穿其中的，不是一个产品吞掉另外两个，而是同一种工作理念，出现在三个不同的层次。
欢迎告诉我你的看法。
如果系统需要更清晰的实施路径，可以了解软件架构咨询。