正儿八经 - 资深技术专家

前几天我读了 OpenAI 那篇文章：Harness engineering: leveraging Codex in an agent-first world。

我读完最大的感受不是“AI 又强了”，而是另一个更接地气的结论：

很多时候，不是模型不够强，而是你的工程环境没有把“正确性”暴露给模型。

这两天我正好在自己项目里处理一个非常典型的问题：运营端新增门店和校验门店名时，如果和其它租户重名会误报；员工后台接口也有类似的租户范围问题。表面上看只是个 tenantId bug，但整个过程把一个事实暴露得很彻底：

AI 想高效干活，前提不是 prompt 更长，而是 harness 更清楚。

一、这次 bug 表面是租户问题，实质是“环境表达不清”

最初的现象其实很迷惑：

1. 运营端调用 admin/store/checkName
2. 明明传了 tenantId
3. 但接口判重却像是按别的租户在查

如果只看 Controller 参数，你会以为“不是都传进来了吗”。
但真正往下追，就会发现系统里其实混着两套租户来源：

• 请求里显式传入的 tenantId
• 线程上下文里的 TenantContextHolder

理论上，TenantContextHolder 也不是错的。因为网关或 filter 确实会从 header 里解析租户并写入上下文。问题在于：

后台管理接口的业务语义，不是‘当前会话属于哪个租户’，而是‘当前运营账号要操作哪个目标租户的数据’。

这两个概念，在多租户后台系统里根本不是一回事。

所以这次真正的问题不是一句“代码写错了”，而是：
系统没有把“哪一个租户才是业务真相”表达得足够显式。

这就是 harness 问题。

二、OpenAI 那篇文章对我最有启发的，不是模型能力，而是“把环境当产品做”

那篇文章里有几层意思我特别认同，我这里不逐字复述，只说我自己的理解。

1）Agent 的上限，很大程度取决于它能不能直接看到真实运行环境

如果模型只能读代码，看不到：

• 实际 HTTP 请求长什么样
• token 从哪里来
• 当前服务到底连的是哪套数据库
• 逻辑删除字段的业务语义是什么

那它就很容易陷入一种“静态推理正确，动态结论错误”的状态。

这次我们项目里就连续遇到了：

• 代码已经改了，但运行中的服务没重启
• checkName 返回 true/false 的语义，调用方理解反了
• 数据库里能查到门店记录，但那条记录其实已经逻辑删除

这些都不是大算法问题，而是工程上下文没有被收束成一个可验证的工作台。

2）入口文档不该是经验大杂烩，而应该是导航页

以前很多项目的 AGENTS.md、模块说明文档，最后都会越写越长。
每次踩坑补一条，最后谁都不想看，AI 也很难稳定执行。

所以我这次顺手把项目里的规则做了一个调整：

• AGENTS.md 和 CLAUDE.md 保留高层原则
• 具体的联调、token、租户、契约规则下沉到 docs/testing/

这不是为了“文档好看”，而是为了让规则能被持续修正，而不是散落在三个地方互相漂移。

3）真正有价值的，不是“写了规则”，而是“规则能被验证”

如果规则只是：

• 显式传 tenantId
• 统一走网关
• 做真实 HTTP 测试

那它还是有点抽象。

真正有效的规则必须长成下面这样：

• 运营端接口测试时，直接向用户索取运营端 token
• 同一个 token，对照请求 tenantId=A/B
• 至少保留一条原始 HTTP 响应
• 必要时补查数据库解释“为什么接口返回这样”

一旦规则写到这个粒度，AI 和人都更难自欺欺人。

三、这次我把项目规则怎么改了

结合这次联调前后对比，我最后把项目里的规则改成了三层。

第一层：入口文档只讲方向，不再堆细则

我在项目根目录 AGENTS.md 和 goodsop-app-server/CLAUDE.md 里增加了一个明确入口：

• docs/testing/README.md
• docs/testing/admin-http-harness.md
• docs/testing/tenant-data-scope.md

意思很简单：
入口文档只负责告诉 AI“去哪儿看”，真正经常变化的实战规则集中维护。

第二层：把运营端 HTTP harness 写成可执行规则

这次新增的 admin-http-harness.md 里，我重点固化了几件事：

1. 所有运营端联调统一走 http://localhost:9999
2. 测试运营端接口时，必须直接问用户要 token
3. 同一轮验证里，优先用同一个 token 只切换 query tenantId
4. 每次改动至少保留 1 个真实业务接口的原始响应
5. 失败排查顺序固定为：连通性 -> 网关 -> Nacos -> 鉴权上下文 -> 业务代码/SQL

这几条看起来朴素，但非常关键。因为 agent 一旦没有这些硬边界，就会在“如何拿 token”“是不是该直连服务”“这个请求到底算不算验证”上浪费很多轮次。

第三层：把租户数据范围语义写明白

tenant-data-scope.md 里，我把这次最核心的结论直接写死了：

1. 后台管理接口的数据范围以显式传入的目标 tenantId 为准
2. TenantContextHolder 是上下文机制，不是后台业务真相
3. checkName/checkPhone 必须同时校验接口契约和逻辑删除语义

尤其是第三点，这次特别有代表性。

我们一开始看到有些门店名“库里明明有记录，接口却返回可用”，很容易怀疑代码没改对。
后来一查数据库才发现：那几条是逻辑删除记录。也就是说，数据库里有行，不等于业务上仍占用名称。

这个结论如果不被写进规则里，下次还会重复争论。

四、这次代码层面的前后对比，也很说明问题

如果只看代码，这次改动其实不算复杂，核心就是两件事。

改动前

• Controller 收到了 tenantId
• 但部分 service 逻辑还是依赖 TenantContextHolder
• checkName 的返回在失败时没有稳定给出 data=false
• 联调时容易把“请求头租户”“目标业务租户”“逻辑删除记录”混在一起

改动后

• admin/store/*、admin/consultant/* 显式把 tenantId 往下传
• 需要上下文的地方用 TenantBroker.applyAs(tenantId, ...)
• checkName 改成：
  • 可用：data=true
  • 不可用：data=false
• 真实接口回归不只看代码，还做了：
  • tenantId=5584 与 tenantId=1 对照请求
  • 门店新增、关店、员工新增、修改、离职
  • 必要时补查 PG 解释结果

这里最关键的，不是“把某个 if 改对了”，而是从“我觉得这样应该对”变成了“我能证明它对，而且能解释为什么”。

这就是 harness 的价值。

五、对我们这种业务项目来说，AI 真正缺的不是智商，而是工作台

很多人谈 AI Coding，喜欢把重点放在模型选择、prompt 技巧、上下文窗口大小。

这些当然重要，但我现在越来越觉得，对真实业务项目来说，下面这些东西更值钱：

1）可直接使用的环境入口

• 正确的网关地址
• 正确的 token 获取方式
• 正确的数据库连接信息
• 正确的日志和服务发现排查路径

2）可复用的验证脚本或验证模板

不是“你自己去测一下”，而是给出：

• 请求地址
• header
• body
• 对照 tenantId
• 预期差异

3）不会漂移的规则系统

很多团队的问题不是没有规则，而是规则散在聊天记录、群公告、项目文档、某个人脑子里。

一旦 AI 进场，这种问题会被放大得更厉害。
因为 AI 特别依赖“哪个文档才是 system of record”。

六、我准备继续往前做的，不只是写博客

这次规则改完以后，我更想补的是一套更完整的 harness，而不只是几段说明文档。

如果继续做，我下一步大概率会补这些东西：

1. scripts/verify-admin-store.sh
   • 自动完成 page/checkName/create/close
2. scripts/verify-admin-consultant.sh
   • 自动完成 page/checkPhone/create/update/resign
3. 运行态环境说明
   • 当前服务实际连接哪套 PG/Redis
4. 接口契约回归样例
   • 尤其是 data/code/msg 这种容易被误解的接口

因为写到最后我越来越确信一件事：

AI 工程化的竞争力，不是“谁的模型更像天才”，而是“谁先把自己的真实环境整理成一个不会误导 agent 的工作台”。

结语

OpenAI 那篇文章给我的最大提醒，是别把 agent 当成一个只会补代码的聊天机器人。

它更像一个能力很强、速度很快，但极度依赖环境质量的工程协作者。

如果你的环境是模糊的：

• 文档入口混乱
• token 获取方式混乱
• 租户语义混乱
• 接口契约混乱

那 AI 就会在这些噪音里反复打转。

但如果你把 harness 补起来，很多原来需要人肉盯着的事情，就会突然顺很多。

所以这次一个看似普通的 tenantId bug，最后给我的启发反而比 bug 本身更大：

以后优化 AI Coding，不只是继续追模型，也要继续做环境。

前两天看到一篇文章，讲一个团队是怎么被 OKR 搞废掉的。

我看完第一反应不是震惊，而是熟悉。太熟悉了。

这种剧情我不光看过，还真切经历过。大厂见过，创业公司也见过，而且每次套路都差不多。通常一开始业务还过得去，大家都忙着打仗，没人太在意考核这套东西。可一旦效益不好了，增长慢了，或者老板心里开始发虚了，OKR、KPI、周报、日报这些东西，往往就会突然变得重要起来。

然后团队就开始慢慢变形。

我在大厂第一次明显感受到这股味儿

那次大概是某年 Q3，公司股价跌了一波。上面开了几轮会，最后落下来一个词，叫“精细化管理”。

这词听着挺中性，甚至还有点高级，但翻译成人话，其实很多时候就是：开始抓考勤、抓周报、抓对齐、抓留痕。

我们组之前其实挺松的。活干完了，产品也上了，大家喘口气是很正常的。没什么事的时候，下午早一点走，也没人专门盯。那种状态未必完美，但至少大家注意力是在做事上的。

结果那段时间开始，节奏一下就变了。

• 每周一早上要站会，每个人说上周做了什么，这周准备做什么
• 周五要复盘，OKR 进度必须填进系统
• 日报、周报开始抄送更多层级
• 迟到早退这些以前没人太在意的事，也开始被认真统计

我当时带一个小团队，最明显的感受不是“管理加强了”，而是大家开始演了。

写代码的时间少了，写“证明自己在工作”的东西多了。注意，不是那种真正帮协作提效的文档，而是那种为了方便往上汇报、方便自证清白、方便出了问题别算到自己头上的文档。

有个同事我印象挺深。以前他遇到问题，直接拉人说两句，半小时可能就搞定了。后来不一样了，得先把背景写清楚，把问题写清楚，把影响写清楚，再写几个方案，最后约个会统一口径。一件原本半小时能搞完的事，最后能拖成两天。

我问他，为啥不直接说？

他说得也很实在：“现在不是讲流程、讲留痕吗？不留痕，到时候出事了怎么算？”

你看，这就是问题。

考核和管控一旦上强度，很多人的第一反应就不是怎么把事做好，而是怎么先保护自己。

创业公司的版本，通常更直接，也更荒诞

后来我去过一家创业公司，二十来号人，团队不大，早期氛围也不错。老板是技术出身，刚开始大家一起熬夜上线、一起救火，很多事都比较直接，没那么多讲究。

做到第二年，融资开始没那么顺，老板整个人的状态也肉眼可见地紧了起来。

先是开会说要“提高人效”，然后 HR 发下来一个表，让每个人填每天做了什么，以及时间大概怎么分配。再后来，周会慢慢变成一种带检查意味的一对一，老板会直接问：“你这周最核心的产出是什么？”

这种问法听着没毛病，但问题是，很多岗位的价值本来就不是按“这周交付了一个什么具体件”来体现的。

我印象很深的一次，是一个产品经理被问急了，说自己这周主要在协调资源、推沟通、解决卡点，没什么特别好拿出来展示的“具体产出”。

老板当时回了一句：“那就是没产出。”

那个产品经理第二周就离职了。

这件事我后来一直记得，不是因为它多戏剧化，而是因为它特别典型。很多管理动作一旦开始变味，最先出问题的，往往就是对“产出”的定义开始变窄了。凡是不好量化的、不能直接截图汇报的、没法马上写成条目的价值，都会被低估。

可现实不是这么运转的。

一个团队里，判断力、协调、补位、把模糊问题想清楚，这些东西很多时候比“今天做完了几个点”重要得多。只是它们更难写进表里。

我后来还跟那个老板聊过一次。我问他，咱们现在才这么点人，抓这么细，真的有必要吗？

他说：“我现在不知道每个人在干什么，心里没底。”

我当时回了一句：你靠抓考核，最后看到的，大概率也只是大家想让你看到的东西。

他没接这个话。

后来我越来越觉得，老板抓考核，很多时候不一定是为了提升效率，更像是在给自己的焦虑找一个抓手。

业务看不清楚，数据不好看，方向又没那么稳，人就会天然地想抓住一些“看得见、数得着、能检查”的东西。于是日报、周报、打分、排名、对齐，就都上来了。

问题是，这些东西最容易抓住的，通常都是表层动作。真正决定成败的那些东西，比如判断是不是对、协作是不是顺、试错是不是有效，反而不太容易量化。

最后就会变成一种很别扭的状态：大家都忙得很认真，但你真要问，忙出来了什么，好像又说不太清。

OKR 和 KPI 本身没原罪，真正容易出问题的是时机和动机

我不是那种逢考核必反的人。

说到底，OKR、KPI 这些东西本身只是工具。在大厂里，它们有存在理由。人多、层级多、链路长、信息天然不透明，你总得有一套机制让目标能往下拆，让结果能往上看。

工具没问题，问题往往出在它是怎么被用起来的。

我自己这些年看下来，有个规律挺明显：

• 业务顺的时候，考核往往没那么重要，很多时候走个形式
• 业务开始承压的时候，考核就会突然被强调
• 老板或者管理层心里没底的时候，考核会迅速精细化

这背后说明的事，其实挺现实的。

很多时候，考核不是拿来提升业绩的，而是拿来缓解焦虑的。

管理层焦虑，组织就会想办法把这种焦虑“落地”；一旦落到一线，通常就会变成更密集的汇报、更细的记录、更重的过程管理。

可焦虑这个东西，往下传一层，就很容易变成内耗。

因为一线接收到的信号不是“怎么把事做成”，而是“怎么证明我没问题”。

一旦组织进入这个状态，很多行为都会自然变形。目标会越定越保守，汇报会越写越漂亮，协作会越来越偏向自保，大家慢慢都知道这套东西不太对，但又只能继续陪着跑。

为什么这套东西一变味，团队很快就会失真

这点其实是我后来才慢慢想明白的。

正常情况下，目标管理本来应该是帮助团队聚焦的。你要解决什么问题，优先级是什么，阶段性打到哪里算过关，大家最好心里有数。

可一旦它和惩罚、排名、证明劳动强度这些东西绑得太死，目标管理就不再是“对齐工具”，而会慢慢变成“表演系统”。

人一旦意识到结果会直接影响评价，第一反应通常不是把目标定得更真实，而是把目标定得更安全。

于是：

• 能模糊的就模糊
• 能保守的就保守
• 能包装的就包装
• 能写得好看的就尽量写得好看

最后所有人都在做一件事：让系统里的自己看起来合理。

这个时候，你看到的数据可能越来越完整，表格可能越来越漂亮，但组织对真实情况的感知反而在下降。

这就是最麻烦的地方。

管理层以为自己抓得更细了，离真相更近了；可实际上，大家只是在更用力地经营“被看见的样子”。

我现在怎么看这件事

说实话，我也做过管理，完全能理解那种“我得知道团队现在到底什么情况”的冲动。团队一大，信息天然会打折，靠拍脑袋肯定不行。

但我现在越来越认同一件事：考核是手段，而且应该是偏后置的手段，不应该是你一上来最先拎出来的东西。

如果一个团队已经开始严重依赖考核来驱动，那通常说明前面已经有东西出问题了。可能是目标没讲清楚，可能是协同机制有问题，可能是信任不够，也可能是业务本身就进入了困难阶段。

这时候你再往上加考核，很多时候就像一个人发烧了，你不去找病因，先一把退烧药压下去。数字可能短期好看一点，动作可能短期整齐一点，但真正的问题还在。

更麻烦的是，这药吃多了，团队会虚。

人会越来越保守，越来越不愿意承担模糊地带的责任，越来越在意“这件事最后怎么评价我”，而不是“这件事到底值不值得做、该怎么做好”。

团队一旦走到这个方向，再想拉回来，成本很高。

给还在坑里的人几句实话

如果你在一家公司，突然发现考核变严了，流程变多了，周报越写越长，汇报越做越细，先别急着反思是不是自己不够努力。

先看业务。

如果业务是好的，这些东西很多时候只是形式主义，未必真会落到你头上，适当配合就行。

但如果业务已经明显承压，而组织又开始把很多精力放到考核、打分、追踪、排名这些事上，那你最好多留个心眼。因为这往往不是转机的开始，更像是管理层开始没底了。

你要判断的是，这到底只是短期波动，还是结构性问题。

如果只是短期波动，扛一扛也许能过去；如果是结构性问题，那你就要想清楚，这家公司后面是准备解决问题，还是准备把压力层层往下传。

这两者区别很大。

我后来不管选团队还是看组织，都会多看一眼：这地方到底是靠什么在驱动？是靠共识、目标和基本信任，还是靠考核、压力和持续盯人？

前者不一定就能成，但至少队伍还像个队伍。

后者短期可能会显得很有执行力，但时间一长，通常都会跑偏。

最后说一句。

OKR 也好，KPI 也好，本来都只是工具。工具本身不会自动变坏，但一旦它开始承担“缓解老板焦虑”“证明组织还在掌控中”这些额外功能，它就很容易变味。

所以很多时候，真正该问的不是“要不要强化考核”，而是：我们现在到底是在解决问题，还是在制造一种自己还控制得住局面的幻觉。

前阵子带团队，踩过一个挺典型的坑：我把上一家大厂里跑得还不错的一整套研发流程，原封不动搬到了创业公司。

我当时还挺有信心的，心想这些东西我都实战过，也验证过，怎么都不至于太差。结果三个月不到，团队效率没上去，情绪先下来了。大家活没少干，但整个人的状态都不对，流程像套在身上的一层壳，怎么动都别扭。

后来我才慢慢意识到一个事：流程这东西，不是越完整越高级，也不是越像大厂越专业，关键是合不合适。

上家公司是成熟中大厂，我们事业部有10个小组左右，通常8 到 9 个人的小组，角色配置相对完整，很多事情都有前提条件托着，标准敏捷那一套跑起来问题不大，比如我带的团队有9个人比现在创业公司带的人还多，工作得比较顺畅，所以我天然认为那套东西是好用的。可创业公司不是这个环境。人少、事杂、变化快，今天定的东西，明天可能就要推翻。这个时候你还想把流程铺得很满，最后大概率不是提效，而是添堵。

下面说几个我自己踩得比较实在的坑。

1. Jira 看板搞得太细，最后大家都在伺候看板

刚开始我把 Jira 也上了，而且沿用了上家公司那种拆法。一个需求要拆到设计、开发、测试、联调，最好还能估到小时，状态流转也尽量完整。

这套东西放在稳定一些的环境里，是有价值的。因为团队规模一大，协作链路一长，你不把信息结构化，很多事情就会乱。

当时我脑子里想的，其实差不多就是下面这种模式。一个板子看起来很清楚，列、卡片、负责人、状态，一眼望过去特别“专业”。

Jira 官方看板示意，来源：Atlassian。

但创业公司不是这么回事。

创业公司最常见的情况是，需求今天这么说，明天又换了；老板上午说先做 A，下午看了竞品又觉得 B 更重要。这个时候看板刚整理清楚，内容就过时了。大家不是在推进任务，而是在不停维护任务卡片，补字段、改状态、对齐口径。

慢慢地，团队开始烦这个东西。那种烦不是嘴上抱怨两句，而是你能明显感觉到，大家觉得在做无用功。

后来我们直接砍掉了这套细颗粒度管理，不再盯单个任务拆得多漂亮，只保留一个比较轻的整体节奏视图，主要看大的节点和关键事项。说白了，就是别再折腾一堆“过程看起来很美”的卡片，先把人从流程里解放出来。

我们后面实际落地的方式，反而很土：一张每日跟踪表，再配一张整体计划表。没有那么多状态流转，也没有那么多字段，但它足够直观，够我们这个阶段用。

这里先放两张我们当时真实在用的图（来源于产品负责人）：

改完以后，大家最直接的反馈不是“这个流程真先进”，而是终于不用天天填东西了。听着很朴素，但这往往说明方向对了。人重新把精力放回到做事本身，效率反而起来了。

2. 详设模板很完整，但完整本身就是负担

我以前的公司，详细设计是比较重视的，而且也确实有它的价值。系统复杂、协作方多、生命周期长，前面多花点时间把设计做扎实，后面能省不少事。

所以到了创业公司，我也想把这个习惯延续下来，要求大家按比较完整的详设模板来。虽然我知道不能照搬原来公司的但是我想着先试着暴露问题再调，
果然问题很快就出来了。

1. 团队成员几乎都没有正儿八经的写过详设，可能是在如今的软件开发，大家完全摒弃或者看不上很多年前的研发流程，所以不重视也不愿意接触。（但是经验告诉我存在既合理，你可以改进单不能完全否定，至少对我来说详设是让你想清楚你要做什么怎么做的过程，其实并不冲突）
2. 创业公司讲究的是快速验证，你先得证明这个东西值不值得做、能不能跑通、市场买不买单。有些模块的生命周期可能很短，有些模块就是很简单的CRUD。这个时候还要求每个需求都搞一份“大而全”的详设，性价比很低。

后来我的调整是，只保留重难点设计。

也就是说，不是不要设计，而是只在真正有必要的地方认真写。比如复杂流程、核心链路、容易出事故的地方，这些该写还是得写，而且要写清楚。至于那些简单页面、普通接口、试验性质的功能，就没必要搞得那么正式，很多时候口头对齐一下，加上关键点同步，也就够了。

模板也顺手砍掉了大半，能简就简。并比如只保留异常处理、数据库设计、关键算法、外部引入说明等章节。

这么改完以后，大家不会因为“要交一份文档”才去写东西，而是因为“这里确实需要想清楚”才写。这个差别挺大。前者容易把写文档变成任务，后者才更接近设计本身。

3. UI 评审流程太正式，节奏根本跟不上

我一开始还认真搭了 UI 评审流程，想着把产品、UI、前端这些角色都拉齐，尽量在正式评审里把问题消化掉。

这个思路本身没错。问题还是那个问题，环境不对。

创业公司很多时候拼的不是“流程是否完备”，而是“反应够不够快”。有时候你这边还在约会、准备材料、等人齐，外面竞品已经上线了。等你一轮会开完，讨论很充分，市场窗口也差不多过去了。

后来我就把这件事彻底做轻了。

多数情况下，前端和 UI 直接碰一下；如果产品逻辑也有争议，就三个人凑一起，当场对齐。能站着说完就别拉长会，能今天拍板就别拖到明天。先把主要分歧解决掉，剩下的小问题边做边收。

这样做当然没那么“规范”，但更符合创业公司的现实。

很多流程设计，表面上是在降低风险，实际上是在用确定性对冲不确定性。可创业公司真正的问题往往不是“讨论不够充分”，而是“动作不够快”。这时候流程越重，可能越错。

4. Sprint 很标准，但标准得有点不合时宜

我之前也试着在创业公司推标准 Sprint，单周也好，双周也好，站会、估时、回顾这些动作都想带起来。

现在回头看，方向有点想当然了。

标准 Sprint 背后有个很重要的前提，就是需求相对稳定，或者至少在一个迭代周期内，不要被打断得太厉害。这样团队才能围绕承诺来组织协作，节奏也才跑得顺。

可创业公司常常不是这种节奏。业务方今天提一个需求，明天就要看结果；线上出了点情况，当前优先级立刻变化；老板临时看到了一个机会，整个排期可能都要让路。

在这种情况下，固定迭代周期很容易从“管理工具”变成“现实阻力”。

你会发现团队嘴上还在讲 Sprint，实际上天天都在被插单。于是形式上很完整，执行上很别扭，大家最后既没享受到 Sprint 的好处，还多了一层心理负担。

后来我就不硬推固定迭代了，更偏向流动式开发。优先保证关键事情快速流过来、快速被处理掉，而不是先想办法把所有事情塞进一个看起来工整的周期里。

说白了，就是别为了流程的完整感，牺牲交付的真实节奏。

5. 工时估得越细，大家越焦虑

还有一个坑也挺常见，就是工时评估。

大厂里很多时候要做资源管理、项目协同、跨团队承诺，所以你会比较强调估时，甚至希望大家估得尽量准一些。这在某些环境下有它的合理性。

但在创业公司里，很多需求本身就带着不确定性。你连边界都没完全看清，非要提前精确承诺到某个点，最后大概率是两头难受。

一头是管理者以为自己拿到了确定性，另一头是执行的人背着一个并不靠谱的 deadline，越做越紧张。

尤其是一些复杂问题，真正难的地方往往在做之前并不能完全看出来。你要求团队给一个很精确的工时，看起来是在做计划，实际上可能是在制造幻觉。

后来我不再盯精确工时，而是更多给出一个大致时间窗口。该说明风险就说明风险，该留缓冲就留缓冲，不再逼着大家把很多本来就估不准的事情说得特别肯定。

结果挺有意思，精确度没那么好看了，但交付反而更可预期了，团队状态也轻松不少。

后来我真正想明白的几件事

1. 创业公司不是大厂缩小版

这个是最核心的一条。

很多人从大厂出来，容易有个潜意识：创业公司只是规模小一点，很多管理动作做轻一点就行了。

其实不是。

这两种组织在很多底层逻辑上都不一样。大厂更多追求稳定、可复制、可预测，流程是拿来放大协作效率、控制系统风险的。创业公司很多时候追求的是快速试错、快速验证、快速调整，它首先得活下来，然后才谈得上优化。

所以你不能简单理解成，大厂那套减配一下就能直接用。

2. 研发天然就不喜欢太重的文字工作

这个事挺现实的，但很多管理动作设计的时候经常假装看不见。

大多数研发真没那么喜欢填表、写一堆过程文档、反复同步那些价值不高的信息。不是因为懒，而是因为他们天然更愿意把注意力放在解决问题、写代码、做实现上。

所以减少无效文档，并不只是为了省时间，本质上也是一种尊重。你尊重一个岗位的工作重心，团队的配合度通常就会高很多。

当然，这不是说文档没用。我的意思只是，别把“有文档”当成默认正确，而是先想清楚，这份东西到底帮了谁，解决了什么问题，值不值得花这个成本。

3. 灵活不等于混乱，底线还是要有

创业公司不适合重流程，不代表什么都可以不要。

有些底线是不能退的，比如代码规范、版本管理、发布安全、线上稳定性这些东西。这些不是“有空再说”的选项，而是基本盘。没有这些，所谓灵活很容易滑成混乱，最后大家都在救火。

我现在更认同的一种状态是：在底线之上尽量灵活。

该守住的东西守住，剩下的就别绑太死。不要一边嘴上说着创业公司要快，一边又把团队拴进一堆并不适合当下阶段的流程里。

什么阶段适合什么模式

如果是成熟一些的中大型团队，人员配置完整，协作链条长，项目复杂度也高，那标准化流程通常是有收益的。它能提升协作效率，也能降低很多因为人多而带来的不确定性。

但如果是小型创业团队，尤其是不到 10 个人的研发团队，我现在的看法会很明确：怎么灵活怎么来，但底线要守住。

不是不要流程，而是只保留那些真正帮你提效的流程。凡是已经开始明显拖慢节奏、压坏情绪、制造无意义劳动的东西，就该果断砍。

最后的话

流程是手段，不是目的。

以前我总觉得，一个团队越专业，流程应该越完整。后来才发现，不是这么回事。真正成熟的团队，不是流程堆得最满的团队，而是知道什么该坚持，什么该省掉，什么阶段该用什么方法的团队。

说得再直白一点，创业公司最怕的不是“不够像大厂”，而是明明身子还很轻，却非要背上一整套大厂的装备。

那玩意儿穿在大厂身上可能是铠甲，穿在创业公司身上，很多时候就是负重。

引言

如果问题变成软件研发对年龄大还是对年龄小的有利好，其实应该用经验更好，但是用经验可能标题就没那么吸引人了。因为经验不等于经历（年龄）。无所谓了，先吸引人你们来看再说。

我相信分歧肯定会很小，因为现实摆在那儿。但是自从AI Coding兴起后，我就开始回过头来重新想这个问题。
AI Coding 起来了，到底是对“大龄程序员”更友好，还是对“年轻程序员”更友好？

如果把这个问题简化成“谁赢谁输”，我觉得答案会很刺耳：谁都可能赢，谁也都可能输。

因为 AI Coding 真正改变的不是“年龄”，而是“价值分布”。有些东西变得很便宜，有些东西反而更贵了。

我之所以对这个话题格外敏感，是因为我自己就是“所谓的大龄开发者”。
我在 34 岁那年带团队招人，脑子里一直有个挥之不去的词：35 岁魔咒。那种“明明还想继续写代码，但市场已经开始用年龄给你贴标签”的感觉，我太熟了。

我试着用结合我的经历来聊一聊，文章会比较长，当然这篇文章完全是我个人观点，我尽量少做评价，少被喷。我知道很有可能会有人喷我，但是还是劝一句不要上升高度不要过度带入 。

一、先别急着站队：这里的“年龄”到底在指什么？

所谓“大龄”“年轻”，很多时候说的不仅仅是身份证上的数字，而是三件事：

1. 经验的密度：你踩过多少坑、见过多少事故、做过多少取舍。
2. 学习的速度：新工具出来，你是“先试两把”，还是“先观望三个月”。
3. 机会的窗口：你能不能承受试错成本（时间、现金流、家庭压力、职业风险）。

AI Coding 这波浪潮，恰好会把这三件事的差异放大。

二、AI Coding 让什么变便宜了？

我先说结论：AI Coding 让“把想法变成可运行代码”的成本显著下降了。

具体来说，至少有三类东西变便宜了：

• 体力型编码：CRUD、胶水代码、重复的重构、样板工程、接口联调的模板化部分。
• 信息检索：查文档、找 API、翻 issue、找最佳实践的“第一跳”成本。
• 尝试与迭代：以前一个想法要半天验证，现在十分钟就能出个“像样的雏形”。

这意味着：只会“把代码敲出来”的能力，正在变成一种越来越普通的能力。

同时也意味着：真正能区分人的部分，正在往上游和下游移动。

• 上游：你能不能把问题定义清楚（需求/约束/边界/风险）。
• 下游：你能不能把结果负责到底（上线质量/稳定性/性能/安全/可维护/可演进）。

AI 写代码是快，但“负责”并不会自动发生。

三、我把同一个问题丢给了几个“顶尖模型”（无前置、无规则）

这里我做了个很“直白”的实验：不加任何前置说明、不设任何规则，就一句话提问，然后直接用它们各自的“最新模板 + 思考模式”拿答案。

原始截图我按顺序贴在下面：口吻不一样、结构不一样，但核心共识其实非常一致——

AI Coding 更像一个“放大器”，不是一张“对某个年龄段的免死金牌”。

我把模型回答里最有用的点，提炼成几条（是提炼，不是逐字复读）：

1）它们普遍认为：对“资深/大龄”的利好更直接

• 经验壁垒被放大：AI 能生成代码，但判断“这段代码对不对、架构合不合理、坑在哪里”，仍然更吃经验。
• 抹平体力优势：年轻人的手速、记 API、找资料的优势，被 AI 大幅抵消；这让大龄不用再去拼“码速”。
• 系统思维更值钱：很多模型都强调了“5 年后系统会怎样”“这个决策对业务的长期影响是什么”——这类能力更难被替代。
• 带团队能力升维：懂得把 AI 变成团队生产力的人，管理价值会更凸显（会用 AI 的人，不一定会让团队用好 AI）。

有个模型还给了一个很戳人的说法：AI 像“超级实习生”——写得快，但并不知道什么是对的；而资深的价值恰好就是“知道什么是对的”。

2）它们也提醒：对“年轻/新人”是双刃剑

• 入门门槛更低，但成长路径更模糊：以前靠 CRUD/修 bug 练基本功；现在 AI 秒生成，练功区变薄了。
• 容易形成“幻觉能力”：能把东西跑起来，但并没真正理解；一旦进线上、进复杂系统，就容易翻车。
• 更难证明自己：当“写出代码”变成普遍能力，面试/协作场景更看重你的思考、取舍、复盘与可靠性。

3）反过来：它们也给了年轻人一个“弯道超车”的入口

有的模型提了个很有意思的反转角度：年轻人如果从一开始就把 AI 当“外骨骼”（而不是“拐杖”），成长速度是指数级的。

我理解这句话的潜台词是：
你可以让 AI 替你省掉很多重复劳动，但你不能把“理解、设计、评审、负责”这四件事也省掉。

读完这些回答，我的第一反应其实不是“谁赢了”，而是更确认了：
AI Coding 放大的是你原本的优势和短板。

原始回答截图

（点击缩略图打开原图）

接下来我讲讲我的真实经历——因为我发现，模型说的这些点，在我的团队里几乎是一比一地出现过。

四、我自己的一个小样本：一支 98/99 团队，和一个“Y”

我先讲个我自己的经历，可能比空谈更有说服力。当然样本不包括我，虽然我可能是团队里工作量最大开发量可能也是最大的，但是因为我的职位以及以及工作能力上来说（削微有点不要脸哈），不太适合跟大家一起比。

我当前所在的公司在创业期，首先待遇和平台确实没法一步到位，但是我还是对招人的要求比较高，因为人没法招的多，所以我希望能进来的人都是能独当一面的。老板这边呢招人偏好很明确：更喜欢年轻的——觉得年轻人有活力、能拼、要的也没那么多。
说实话，这种想法我也能理解，甚至某种程度上我也认同：创业期确实更适配年轻人。但是因为我自己 34 岁，也是大龄开发，所以我也没有完全按所谓的35岁来卡简历，因为我上一家公司学到的很多东西都是从比我年龄还大的人身上学到的。

总之最终招人，团队里大多是 98、99 年左右的同学。另外还有一位年龄跟我相差不大、也算大龄开发者的同事，为了好说明，我就叫他 Y。

人招齐了，几个月共事下来，我被“刺激”得挺狠的——当然这个刺激主要是刺激我。

1）“年轻 = 有拼劲”？至少在我的团队里并不成立

团队里大多数人并没有我想象中那么有拼劲。

我观察下来，初步的感觉是有些同学的精力和注意力很多投放在短视频、短剧、游戏这些东西上。
我伸懒腰的时候瞄到一个同学：左边在 vibe coding，右边短剧放着。我当时一度分不清 vibe 的到底是哪边。

总之给我的体感是：状态不但不“拼”，反而有些消极和懈怠。可能更多的对他们来说就是类似流水线上那种计件工作一样，反正就是干一天就挣一天。（我估计很多人就要喷我了），就是我的意思是啥呢，当然我是old school哈，如果你不讨厌这份工作，那是不是对工作赋予一点其它的价值？比如对自己的锻炼、成长、成就感等

2）有了 AI Coding 以后，反而更暴露“设计与表达”的短板

为了避免 AI 滥用，我提了一个要求：重难点模块必须做设计。

我讲了要求，也给了模板，而且很直白地说：可以借助 AI 来完成设计任务。
但结果很现实：大多数人连“详设里应该写啥”都不清楚，UML 也不太会画，最终交付物一言难尽（说实话，Y 也没例外到哪去）。

我的感受是：很多人不是做不出来，而是压根没把心思放在“把问题讲清楚”以及“怎么解决”这件事上。

3）AI 让代码“飞起来”了，但 CR 一拉：屎山也能飞

有了 AI Coding，表面上代码写得很快。
但一到 Code Review，屎山代码一大堆：结构乱、边界不清、异常兜不住、测试缺失……一旦出 bug 就会变成“补丁套补丁”的恶性循环。

后来确实没办法，我让其中一位代码问题很严重的同学离开了。
他那块业务的 bug 多到修不完，修到后面甚至发现没法修——因为他自己找不到根本原因，只能不断打补丁，然后继续恶心循环。

我接手重构，前后花了差不多两周时间。

这里也顺带提一句：虽然 Y 的代码也有一些问题，但总体是可控的，不用担心暴雷。
我猜原因有两个：一是他比较遵守规则（我提的要求大多能做得比较到位），二是他大概有 10 年左右的开发经验，能在一定程度上“指导 AI 怎么干活”。

这三个刺激让我更确信一件事：AI Coding 把“写代码”这件事变得更容易了，但把“写对代码”这件事变得更重要了。

五、对年轻程序员：利好很大，但坑也很深

1）利好：入场门槛变低，反馈速度变快

对年轻人最直接的利好是：你可以更早做出完整作品。

以前你要先攒很久“基础设施能力”：脚手架、工程化、框架细节、各种配置地狱……
现在这些都能被 AI 帮你跨过去一大截。

于是你能更快进入“真正的战场”：

• 做一个能跑的产品/工具
• 去真实用户那里挨骂
• 在反馈里快速迭代

这对成长是好事，甚至是非常好的事。

2）坑：把“生成”误当成“掌握”

但年轻人也更容易踩一个坑：以为自己会了，其实只是 AI 会了。

你会发现项目能跑、功能能用，但一旦出现下面这些情况，就开始头皮发麻：

• 线上偶发 bug，日志看不懂
• 性能抖动，不知道从哪儿下手
• 需求一改，牵一发动全身
• 加一个看似简单的功能，最后变成“屎山滚雪球”

说得更直白一点：
AI 能帮你跳过一些“枯燥”，但跳得太狠，也会错过一些“肌肉训练”。

年轻人的关键不是“用不用 AI”，而是“能不能把 AI 变成你的教练，而不是代打”。

六、对大龄程序员：利好也很大，但会更“残酷”

1）利好：经验被放大，稀缺能力更稀缺

大龄程序员的优势，通常不在“手速”，而在“判断”：

• 方案取舍：这事该用微服务吗？该上 MQ 吗？该引入新框架吗？
• 风险感知：哪里会炸、什么时候会炸、炸了怎么兜底
• 复杂协作：跨团队、跨系统、跨角色（产品/运营/安全/法务）的落地能力

AI Coding 让“写”的成本下降后，判断的价值反而会更凸显。

因为系统越容易被搭起来，系统也越容易被搭坏；
上线越快，事故也来得越快。

这类场景里，经验不是包袱，经验是护城河。

2）残酷：如果你把自己定义成“高级码农”，会被挤压得很厉害

更残酷的一面是：有一类“大龄”会很难受——
不是因为年龄大，而是因为他过去十年把自己训练成了“熟练工”：

• 熟练地堆功能
• 熟练地应付需求
• 熟练地修修补补

当 AI 把“熟练工”这块压到极致性价比后，这条赛道会非常拥挤。

不是 AI 淘汰大龄，而是“只剩熟练”会被淘汰。

七、真正的分水岭：谁能“问对问题 + 做对取舍 + 负责结果”

如果要我给一句话版本的答案：

AI Coding 的利好，不属于某个年龄段，属于“能把 AI 当成杠杆的人”。

你能不能：

• 把问题说清楚（目标、约束、边界、验收标准）
• 把方案选对（可维护、可观测、可扩展、成本可控）
• 把结果交付（线上稳定、可追踪、能迭代、能复盘）

这三件事，AI 都能参与，但 AI 都不能替你承担。

八、我给两类人的具体建议（尽量可执行）

给年轻程序员的 5 条

1. 把 AI 当“解释器”：让它解释你不懂的代码、让它画调用链、让它写测试，而不是只让它“写功能”。这方面稍微用点心就会发现有一堆skill或者提示词可提升让AI写”准“的能力。
2. 刻意练基本功：调试、日志、性能、并发、网络、数据库索引，这些是你未来十年的复利。
3. 做真实项目：哪怕是一个很小的工具，能被别人用，比刷十套题更接近现实。
4. 训练问题定义：每次让 AI 干活前，开启PLAN模式，先反复交流，让双方都搞“我到底要什么”，这是最值得投入的能力。
5. 保留手写能力：不是为了炫技，是为了在关键时刻你能掌控复杂度。

给大龄程序员的 5 条

1. 别抗拒工具，抗拒的是落后感：先用起来，哪怕从“写测试/写文档/写脚本”这种低风险场景开始。比如我几乎试遍了主流的所有AI模型和AI工具，比如Codex、Claude code、Opencode、GLM、Minimax、Antigravity、Cursur、kimi-cli、Kiro等，每次都很兴奋，我会不断用他们在我的工作任务中尝试，最终筛选出来我最顺手的。（当然这个过程又是另一个故事了）。
2. 把经验产品化：把你脑子里的“事故清单”“选型原则”“排障套路”写出来，变成团队资产。你要能快速的把你多年的积累分类并补全（可靠AI），随时抽取出来给到AI使用。
3. 强化架构与质量话语权：可观测性、灰度、回滚、SLA、成本模型……这些会越来越值钱。
4. 练提示词，但更要练评审：你不是比谁会 prompt，你是比谁能看出生成代码的坑。你要能评估AI的方案是否合理。
5. 把自己从“写代码的人”升级为“交付结果的人”：能把事情做成的人，永远稀缺。

结尾

当然看到这儿，肯定有人会说我是在和稀泥一顿输出孟如虎，但是又好像啥没说，那咋可能呢，我可是很不喜欢和稀泥的。

所以回到最开始的问题：AI Coding 的兴起，是对谁的利好？

我的答案比较乐观是：利好年龄大的开发者，因为在我看来，从当前现状分析，就算各有利好，那就算趋近55开了，相比之前的3/7开甚至1/9开是不是提升？当然还是得补一句和稀泥的话。
对愿意重新学习的人利好，对愿意承担结果的人利好，对愿意把经验变成杠杆的人利好。

年龄只是你当前的状态，AI 才是这场变化的放大器。

你站在放大器的哪一边，取决于你接下来三个月怎么过。
我自己 34 岁那次带队招人、带队落地，被那一轮“刺激”按在地上摩擦之后，反而更确定了：真正的安全感不是年龄给的，是你把“负责结果”的能力练出来之后，自然长出来的。

当然到底工作能力高低应该怎么评价，那就是另一个故事了。如果有幸可以发挥，我后续会来一篇。

前几天刷到个帖子，给我看傻了。

一个开发老哥，用 AI 智能体集群，一个人干了整支开发团队的活。不是 Demo，不是 toy project，是正经在跑的 B2B SaaS，还在产生真实收入。

这数据太离谱了

单日最高 94 次代码提交，日常平均 50 次。

最快 30 分钟合并 7 个 PR，需求从提出到上线通常当天搞定。

关键是，这些代码直接变成真金白银的 经常性收入。

整套系统跑下来，月均成本 190 美元，最低 20 美元就能起步。

这哥们儿叫 Elvis，已经把架构开源了。核心是个叫 OpenClaw 的智能体编排系统。

核心痛点：上下文窗口不够装

直接拿 Codex 或 Claude Code 写代码？那是老黄历了。

问题在于上下文窗口的零和博弈——代码塞多了，业务逻辑装不下；塞满客户历史，又看不懂代码库。

就像拿个小杯子装东西，代码和业务背景只能二选一，怎么都不够使。

破局的关键是：把业务跟代码解耦。

OpenClaw 是干嘛的

简单说，它是人和大模型之间的”翻译官”。

这个编排器叫 Zoe，直接读 Obsidian 里的客户数据、会议记录、历史决策，把业务上下文翻译成机器能懂的提示词。

有意思的是，这跟 Stripe 之前披露的 Minions 系统思路很像，但完全跑在本地。

工作流：极度克制的自动化

需求确定后，Zoe 干这几件事：

1. 调管理员 API 解除客户限制
2. 拉生产数据库的只读配置塞进提示词
3. 给每个智能体分配独立的 git worktree 和 tmux 会话

1
2
3
4
5

git worktree add ../feat-custom-templates -b feat/custom-templates origin/main
cd ../feat-custom-templates && pnpm install
tmux new-session -d -s codex-templates \
  -c /Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates \
  $HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high

然后唤醒编码智能体：

1
2
3
4
5
6
7
8

codex --model gpt-5.3-codex \
  -c model_reasoning_effort=high \
  --dangerously-bypass-approvals-and-sandbox \
  "Your prompt here"

claude --model claude-opus-4.5 \
  --dangerously-skip-permissions \
  -p "Your prompt here"

tmux 这个用法挺妙

发现方向偏了，不用杀进程，直接往终端发指令强行纠偏：

1
2

tmux send-keys -t codex-templates "Stop. Focus on the API layer first, not the UI." Enter
tmux send-keys -t codex-templates "The schema is in src/types/template.ts. Use that." Enter

任务状态实时写进 .clawdbot/active-tasks.json：

1
2
3
4
5
6
7
8
9
10
11
12

{
  id: "feat-custom-templates",
  tmuxSession: "codex-templates",
  agent: "codex",
  description: "Custom email templates for agency customer",
  repo: "medialyst",
  worktree: "feat-custom-templates",
  branch: "feat/custom-templates",
  startedAt: 1740268800000,
  status: "running",
  notifyOnComplete: true
}

跑完自动更新：

1
2
3
4
5
6
7
8
9
10
11
12

{
  status: "done",
  pr: 341,
  completedAt: 1740275400000,
  checks: {
    prCreated: true,
    ciPassed: true,
    claudeReviewPassed: true,
    geminiReviewPassed: true
  },
  note: "All checks passed. Ready to merge."
}

监控：低成本轮询

用 cron 每 10 分钟跑一次确定性 Shell 脚本。

.clawdbot/check-agents.sh 检查会话状态、调 gh cli 验证 CI，卡住了自动重试最多 3 次。

代码提交门槛很高：TypeScript 检查、单元测试、Playwright 端到端测试，一个都不能少。UI 改动还必须带截图，否则 CI 直接拦下。

Code Review：三模型交叉验证

这套审查机制挺有意思：

• Codex：抓逻辑错误、竞态条件这些核心坑
• Gemini：盯安全漏洞和架构扩展性
• Claude Code：打辅助，做冗余验证

三个模型互相盯着，比单一模型靠谱多了。

改良版拉尔夫循环

底层跑的是改良版拉尔夫循环。

Zoe 不是机械地复用静态提示词，而是带着全局业务上下文去救场，动态调优失败的节点。

更狠的是，它还能自己找活干：

• 早上扫 Sentry 日志，自动派修复工单
• 开完会解析记录，提取功能需求
• 晚上梳理 git 日志，生成更新文档

基本不用人催，自己就把活儿干了。

模型分工很明确

不同模型干不同的事，不瞎折腾：

• Codex：90% 的复杂后端和跨文件重构
• Claude Code：前端构建和 git 操作
• Gemini：UI 设计环节输出规范文档

各干各的擅长的，效率最高。

部署：10 分钟搞定

最爽的是部署。把架构文档扔给 OpenClaw，10 分钟 内全自动完成脚本生成和目录搭建。

基本上就是”一键开店”的感觉。

唯一的瓶颈：内存

现在卡脖子的只有硬件内存。

每个独立工作树加并发编译环境，都在疯狂吃内存。

16GB 的 Mac mini 并发 4-5 个智能体就开始Swap了。

老哥已经下单了 3500 美元的 M4 Max Mac Studio（128GB 内存），准备突破并发上限。

一人公司时代真要来了

基于这套系统做的公关工具 Medialyst.ai 已经在落地。

不是概念验证，是真的在赚钱的一人企业。

我的一点想法

说实话，这事儿给我的震撼挺大的。

不是那种”AI 好牛逼”的震撼，而是”原来真的可以这么干”的震撼。

单人开发团队不是空谈，已经有人跑通了。关键不是某个模型多强，而是怎么让多个模型协同起来。

OpenClaw + Codex/CC 这个组合，给了一个很清晰的方向：

编排比模型本身更重要。

传统软件开发那套流程正在被重塑。以前需要产品经理、开发、测试、运维一堆人干的事，现在一个人加一堆智能体就能搞定。

一人公司的时代，可能比我们想象的来得更快。

参考链接：https://x.com/elvissun/status/2025920521871716562

缘起

前段时间写了 OpenClaw 那篇文章，讲怎么用编排层管理多个 AI 代理。最近发现一个 GitHub 项目 wshobson/agents，这是一个专门为 Claude Code 打造的多智能体编排系统。不是那种概念性的演示，而是真刀真枪的生产级工具。

让我震撼的几个数字：

• 112 个专业 AI Agent
• 16 个多智能体工作流编排器
• 146 个 Agent Skills
• 79 个开发工具
• 72 个独立插件

这已经不是”用 AI 辅助编程”了，这是用 AI 团队替代开发团队。

核心架构：插件化设计

wshobson/agents 最聪明的设计是插件化。

它不是给你一个大而全的系统，让你把所有东西都加载进来。而是拆成 72 个独立的插件，每个插件只做一件事，但做到极致。

为什么要插件化？

上下文窗口是有限的资源。如果你一次性加载 112 个 Agent 和 146 个 Skills， token 消耗会爆炸。

插件化的解决方案：按需加载。

举个例子：

1
2

# 安装 Python 开发插件
/plugin install python-development

这个插件只加载：

• 3 个 Python 专业 Agent
• 1 个脚手架工具
• 16 个专业 Skills

总共约 1000 个 token，而不是整个市场的几万 token。

插件的分类

72 个插件分成 24 个类别，每个类别 1-6 个插件：

这种结构的好处是：想用啥装啥，绝不多加载。

三层模型策略

这个项目最让我印象深刻的是它的模型分层策略。

不是一刀切地用同一个模型，而是根据任务复杂度分配不同的 Claude 模型：

为什么 Opus 4.6 负责关键任务？

几个硬指标：

• SWE-bench 80.8% — 行业领先
• 复杂任务 token 减少 65%
• 最适合架构决策和安全审计

虽然 Opus 单价高（$5/$25 每百万 token），但因为 token 效率更高，实际成本往往更低。

Tier 2 的灵活性

Tier 2 的 Agent 标记为 inherit，意思是使用你当前会话的默认模型。

怎么用？

1
2
3

# 启动会话时指定模型
claude --model opus    # 需要高强度时用 Opus
claude --model sonnet  # 日常开发用 Sonnet

这样你可以根据当前任务灵活选择，不用改配置。

Agent Teams：真正的并行工作流

这是我觉得最实用的功能：多智能体并行。

安装 Agent Teams 插件：

1

/plugin install agent-teams@claude-code-workflows

7 个预设团队

实战示例：并行代码审查

1

/team-review src/ --reviewers security,performance,architecture

这个命令会：

1. 启动 3 个审查 Agent（安全、性能、架构）
2. 每个 Agent 独立审查代码
3. 汇总结果，生成综合报告

传统的代码审查是串行的：一个人看完再给下一个人。现在是三个人同时看，时间从几小时缩短到几分钟。

实战示例：假设驱动调试

1

/team-debug "API returns 500" --hypotheses 3

系统会：

1. 生成 3 个关于 500 错误的假设
2. 每个假设分配一个 Agent 去验证
3. 并行执行验证
4. 返回最可能的根因

这比一个人一个个尝试 hypotheses 快多了。

Conductor：项目管理的 AI 化

另一个强大的插件是 Conductor，它把 Claude Code 变成了项目管理工具。

1

/plugin install conductor@claude-code-workflows

核心工作流

1. 交互式项目初始化

1

/conductor:setup

这个命令会：

• 创建产品愿景
• 确定技术栈
• 定义工作流规则
• 生成代码风格指南

2. 基于 Track 的开发

1

/conductor:new-track

生成规格说明和分阶段实施计划。

3. TDD 工作流

1

/conductor:implement

执行任务，带验证检查点。

4. 语义化回滚

1

/conductor:revert

按逻辑单元回滚（track、phase 或 task）。

状态持久化

项目上下文跨会话持久保存。你今天设置的项目，明天打开 Claude Code 还能继续。

Skills：渐进式知识披露

146 个 Skills 是 wshobson/agents 的知识层。

每个 Skill 是一个专门的知识包，遵循渐进式披露架构：

Skills 的分类

语言开发：

• Python（5 个）：async 模式、测试、打包、性能、UV 包管理
• JavaScript/TypeScript（4 个）：高级类型、Node.js 模式、测试、ES6+

基础设施：

• Kubernetes（4 个）：manifest、Helm、GitOps、安全策略
• 云基础设施（4 个）：Terraform、多云、混合网络、成本优化
• CI/CD（4 个）：流水线设计、GitHub Actions、GitLab CI、密钥管理

AI/ML：

• LLM 应用（8 个）：LangGraph、Prompt Engineering、RAG、评估、embedding、相似性搜索、向量调优、混合搜索

区块链：

• Web3（4 个）：DeFi 协议、NFT 标准、Solidity 安全、Web3 测试

激活示例

当你使用 Python 开发插件时，相关 Skills 会自动激活：

1
2
3
4
5
6

用户："创建一个 FastAPI 微服务"

系统激活：
- async-python-patterns
- python-testing-patterns  
- uv-package-manager

你不需要手动选择，系统根据上下文自动加载。

实战：从零搭建全栈功能

让我用一个完整示例展示这套系统的能力。

场景：添加用户认证功能

传统方式：

1. 设计数据库表（1 小时）
2. 写后端 API（4 小时）
3. 写前端页面（4 小时）
4. 写测试（2 小时）
5. 代码审查（1 小时）
6. 部署（1 小时）

使用 wshobson/agents：

1
2
3
4
5
6
7

# 安装必要插件
/plugin install full-stack-orchestration
/plugin install python-development
/plugin install backend-development

# 启动全栈编排
/full-stack-orchestration:full-stack-feature "user authentication with OAuth2"

系统会协调 7+ 个 Agent：

1. backend-architect → 设计 API 架构
2. database-architect → 设计数据库 schema
3. frontend-developer → 实现登录 UI
4. test-automator → 生成单元测试和 E2E 测试
5. security-auditor → 安全审计
6. deployment-engineer → 配置部署
7. observability-engineer → 设置监控

这些 Agent 并行工作，不是串行。

结果：

• 时间从 13 小时缩短到 30 分钟
• 包含安全审计和测试覆盖
• 自动部署和监控

安全加固示例

1
2

/plugin install security-scanning
/security-scanning:security-hardening --level comprehensive

这个命令会启动多 Agent 安全评估：

• SAST 扫描
• 依赖项扫描
• 代码审查
• 合规检查

Python 项目脚手架

1
2

/plugin install python-development
/python-development:python-scaffold fastapi-microservice

自动激活的 Skills：

• async-python-patterns - AsyncIO 和并发
• python-testing-patterns - pytest 和 fixtures
• uv-package-manager - 快速依赖管理

生成的项目包含：

• 生产级 FastAPI 结构
• 异步模式最佳实践
• 完整的测试套件
• Dockerfile 和 docker-compose
• CI/CD 配置

成本分析

大家最关心的：这得花多少钱？

模型成本

实际使用成本

一个小型项目团队（3-5 人）的月度估算：

• 日常开发（Sonnet）：$50-100/月
• 关键架构审查（Opus）：$30-50/月
• 自动化任务（Haiku）：$10-20/月

总计：$90-170/月

对比：

• 一个初级开发者的工资：$3000-5000/月
• 这个系统的成本：1/30

ROI 非常明显。

省钱技巧

1. 用 inherit 模式灵活选择模型

   • 日常开发用 Sonnet
   • 关键任务切换到 Opus

2. 合理拆分任务

   • 大任务拆成小任务
   • 减少单次调用的 token 消耗

3. 利用 Skills 的渐进披露

   • 只在需要时加载详细知识
   • 避免不必要的资源加载

与 OpenClaw 的对比

有人可能会问：这个和之前写的 OpenClaw 有什么区别？

我的建议：

• 如果你已经在用 Claude Code，直接上 wshobson/agents
• 如果你需要更灵活的编排或有特殊需求，考虑 OpenClaw
• 两者也可以结合：用 OpenClaw 做高层编排，wshobson/agents 做具体执行

个人思考

用了一段时间 wshobson/agents，有几个感触：

1. 专业化分工是趋势

不是让一个大模型做所有事，而是让多个专业 Agent 各做各的。

就像真正的开发团队：

• 架构师做设计
• 后端写 API
• 前端做界面
• 测试写用例
• 运维管部署

AI Agent 也在走这条路。

2. 编排层的价值被低估了

很多人关注单个 Agent 的能力，但编排层才是放大器。

好的编排可以让 10 个普通 Agent 发挥 100 个 Agent 的效果。

3. 上下文管理是关键

wshobson/agents 的插件化和渐进披露设计，本质上是在解决上下文管理问题。

有限的上下文窗口 → 按需加载 → 最大化利用

这是所有 AI 系统都要面对的挑战。

4. 成本可控比想象中容易

很多人被 Opus 的价格吓到，但：

• 大部分任务用 Sonnet 就够了
• Opus 的 token 效率更高
• 合理分层后，实际成本很低

5. 未来是”人机协作团队”

不是 AI 替代人类，而是人类+AI 团队替代传统团队。

一个产品经理 + wshobson/agents = 一个完整开发团队

这不是科幻，是现在就能实现的事。

如何开始

第一步：添加插件市场

1

/plugin marketplace add wshobson/agents

第二步：浏览可用插件

1

/plugin

第三步：安装你需要的

1
2
3
4
5
6
7
8
9
10
11
12

# 基础开发
/plugin install python-development
/plugin install javascript-typescript

# 代码审查
/plugin install comprehensive-review

# 全栈工作流
/plugin install full-stack-orchestration

# 多智能体团队
/plugin install agent-teams

第四步：开始使用

1
2
3
4
5
6
7
8

# 并行审查
/team-review src/

# 全栈功能开发
/full-stack-orchestration:full-stack-feature "your feature"

# Python 脚手架
/python-development:python-scaffold your-project

写在最后

wshobson/agents 让我看到了 AI 辅助开发的下一个阶段。

不是更好的单轮对话，不是更长的上下文窗口，而是系统化的多智能体协作。

112 个 Agent、16 个编排器、146 个 Skills — 这些数字背后是一个清晰的愿景：

让一个人拥有整个团队的能力。

这不是取代人类，而是给人类超能力。

你仍然是决策者、架构师、审查者。但执行层面的工作，可以交给这个永不疲倦的 AI 团队。

未来已来，只是分布不均。

参考

• 项目地址：https://github.com/wshobson/agents
• Claude Code 文档：https://code.claude.com
• Agent Teams 文档：项目中查看 /agent-teams
• Conductor 文档：项目中查看 /conductor

背景

最近在 GitHub 上看到个项目,叫 Strix。

看了一下,这玩意挺有意思的。像黑客一样的 AI 智能体,用来做安全测试。

简单说,就是一群 AI 代理,像黑客一样攻击你的应用。做个记录，方便后续需要时查看使用。

Strix 是什么

根据官方介绍:

Strix 是开源的 AI 智能体安全测试平台。

它的核心思想:让多个 AI Agent 协作,自动发现和修复安全漏洞。

核心特点

• 多智能体协作:多个 Agent 一起工作
• 真实验证:用 PoC 概念验证漏洞
• 自动修复:生成可修复的 PR
• 快速反馈:CI/CD 集成
• 低误报:减少假阳性

核心能力

1. 应用安全测试

Strix 可以对任何应用进行全面的安全测试:

• 漏洞发现:自动识别常见漏洞
• 渗透测试:模拟真实攻击场景
• 验证测试:PoC 验证
• 安全审计:全面安全评估

2. Agent 协作

这是 Strix 的核心。

多个 AI Agent 像黑客团队一样工作:

• 有些负责扫描
• 有些负责攻击
• 有些负责验证
• 有些负责报告生成

好处:

• 并行处理,速度快
• 全覆盖,不遗漏
• 模拟真实攻击,更精准

3. 代码分析

静态和动态代码分析能力:

• 静态分析:SAST/DAST
• 依赖检查:第三方库安全扫描
• 配置审计:安全配置检查
• 代码质量:安全相关代码质量检查

4. Web 安全

针对 Web 应用的安全测试:

• XSS 检测:跨站脚本攻击
• CSRF 防护:跨站请求伪造
• SQL 注入检测:数据库注入攻击
• 命令注入:系统命令注入攻击

5. API 安全

API 安全测试能力:

• 认证测试:API 认证机制
• 授权测试:API 授权和权限
• 速率限制:API 限流测试
• 数据泄露:敏感数据泄露检测

快速开始

环境要求

• Docker 运行
• LLM API Key (OpenAI/Anthropic/Google 等)
• Python 3.8+

安装

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 克隆仓库
git clone https://github.com/usestrix/strix.git

# 进入目录
cd strix

# 安装依赖
pip install -r requirements.txt

# 配置 API Key
export STRIX_LLM="openai/gpt-4"
export LLM_API_KEY="your-api-key"

# 运行首次扫描
strix --target ./your-app-directory

配置说明

首次运行会自动:

• 拉取 Docker 镜像
• 启动沙箱环境
• 运行安全扫描
• 生成报告

使用场景

场景一:GitHub 仓库安全测试

1
2

# 扫描 GitHub 仓库
strix --target https://github.com/your-org/your-repo

Strix 会:

• 扫描代码仓库
• 检查依赖安全问题
• 生成安全报告
• 创建修复 PR

场景二:本地代码库测试

1
2

# 扫描本地代码
strix --target ./my-codebase

扫描:

• 所有 Python/JavaScript 文件
• 配置文件安全检查
• 硬编码密钥检测
• 敏感信息泄露检测

场景三:Web 应用渗透测试

1
2

# 渗透测试
strix --target https://your-app.com --mode penetration

Agent 会:

• 自动发现登录页面
• 尝试常见攻击
• 测试权限绕过
• SQL 注入测试
• XSS 攻击测试

场景四:自动化 CI/CD 集成

1
2

# CI/CD 安全测试
strix --target ./ci-cd-pipeline

测试:

• GitHub Actions 安全配置
• 工作流注入攻击测试
• 密钥泄露检测
• 恶意依赖检测

网络上的实践案例

案例:发现高危漏洞

有安全团队分享了 Strix 的使用经验:

1. 零日漏洞发现

   • Strix 在测试某应用时
   • 发现了一个未公开的漏洞利用
   • 该漏洞被标记为 0day
   • 生成了详细的 PoC

2. 自动化漏洞挖掘

   • 传统的手工挖掘需要数周
   • Strix 用 Agent 自动挖掘
   • 一周内发现 10+ 个逻辑漏洞

3. 误报率降低

   • 静态工具误报率通常 20-30%
   • Strix 通过 AI 验证降低到 3-5%
   • 大幅减少人工审核时间

案例:提高测试效率

某开发团队的对比:

效率提升非常明显。

Strix 平台

除了开源 CLI 工具,Strix 还提供了完整平台:

app.strix.ai

• 可视化界面:Web 界面管理测试项目
• 多项目管理:同时管理多个测试项目
• 团队协作:团队成员共同参与
• 报告生成:自动生成美观的安全报告
• 历史追踪:测试历史和漏洞追踪

功能特性

• 实时监控:测试进度实时查看
• 通知提醒:关键发现自动通知
• 导出功能:多格式导出报告
• API 访问:开放 API 供集成

企业版特性

• SSO 单点登录
• 自定义合规报告
• 专属支持
• 私有化部署

技术架构

前端

• React:用户界面
• Tailwind CSS:样式框架
• Vite 5:构建工具

后端

• FastAPI:Python Web 框架
• Celery:任务队列
• PostgreSQL:数据库

AI 核心

• 多模型支持:支持多个 LLM Provider
• Agent 编排:智能体协调和任务分配
• 知识库:安全知识库和攻击模式

安全沙箱

• Docker 隔离:每个测试运行在独立容器
• 网络隔离:受控网络环境
• 资源限制:CPU/内存限制
• 日志审计:完整操作日志

优势和限制

优势

1. 开源免费:完全开源,免费使用
2. 快速上手:配置简单,5 分钟开始测试
3. 自动化程度高:大部分测试自动完成
4. 社区活跃:GitHub 上活跃,持续更新
5. 多供应商支持:不绑定单一 API,成本可控

局限性

1. LLM 成本:依赖付费 LLM API,测试成本高
2. 技术门槛:需要一定 AI 和安全知识
3. 误报率:虽然降低到 3-5%,但仍需人工验证
4. 资源消耗:多 Agent 并发,资源消耗大
5. 学习曲线:需要学习 Strix 的使用方式

适用人群

安全团队

• 适合需要提高测试效率的团队
• 特别是 AI 驱动的安全测试
• 需要处理大量漏洞报告

开发团队

• 适合想要自动化安全测试的团队
• 可以作为 CI/CD 流程的一部分
• 需要定期进行安全审计的团队

AI 研究者

• 适合研究智能体安全的研究
• 可以作为研究平台使用
• 需要测试新攻击向量的团队

实用建议

1. 从小规模开始

不要一上来就想大规模部署。

建议:

• 先用 Strix 测试一个小项目
• 熟悉工作流
• 验证效果
• 再逐步扩大规模

2. 重视人工验证

虽然 AI 自动化,但人工验证仍然重要。

建议:

• 重点关注高影响漏洞
• 认真审核 AI 发现的问题
• 建立验证标准和流程

3. 合理控制成本

LLM API 成本不低。

建议:

• 选择性价比高的模型
• 用 Strix Router 统一管理多个 Provider
• 设置合理的速率限制
• 监控使用量和成本

4. 结合传统工具

Strix 不是要完全替代传统工具,而是补充。

建议:

• SAST/DAST 工具继续使用
• Strix 用于 Agent 协作和智能分析
• 两者结合,发挥各自优势

5. 学习和贡献

Strix 是开源项目,鼓励社区贡献。

建议:

• 阅读官方文档
• 学习源代码
• 提 Issue 和 PR
• 分享使用经验

写在最后

Strix 代表了AI 驱动的安全测试新方向。

它的核心思想:用一群 AI Agent,像黑客团队一样协作,自动发现和修复漏洞。

优势:

• 测试速度快
• 覆盖率高
• 误报率低
• 自动化程度高

需要注意:

• LLM 成本不低
• 有一定学习曲线
• 仍需人工验证

对于安全团队、开发团队、AI 研究者,都值得关注。

如果你在做 AI Agent 相关开发,Strix 提供了一个很好的参考。

参考

• 项目地址: https://github.com/usestrix/strix
• 官方文档: https://docs.strix.ai
• 平台地址: https://app.strix.ai
• Discord 社区: https://discord.gg/strix-ai

引言

最近在 GitHub 上看到一个项目,叫 moyin-creator。关注这个项目是因为我媳妇儿现在天天看这种二维动画（小说）一天能看好几个小时，而且我看点赞啥的还非常高，有点意思，没想到这么low的这么多人看。先做个记录，后面花时间自己搞一个，实现财富自由？

它不是简单的 AI 视频生成器,而是一套面向 AI 视频创作者的生产级工作流。

简单说,就是从剧本到成片的完整自动化。

项目概览

五大板块

moyin-creator 的工作流分成五个部分:

1. 📝 剧本 - AI 剧本生成
2. 🎭 角色 - AI 角色设计
3. 🌄 场景 - AI 场景构建
4. 🎞 导演 - AI 分镜管理
5. ⭐ S级 - Seedance 2.0 批量生产

这五个板块环环相扣,每一步的产出自动流入下一步。

核心功能

多镜头合并叙事视频生成

这个功能听起来挺高级的。

传统的视频制作,每个镜头单独拍,后期再剪辑。

moyin-creator 用 AI 直接生成多视角合并的叙事视频。

比如,同一场景从三个角度拍,合并成一个连贯的叙事。

好处:

• 不用实际拍
• AI 自动生成不同视角
• 后期剪辑量大幅减少

剧本解析引擎

上传剧本,系统自动解析。

识别:

• 角色
• 场景
• 分镜
• 对白
• 情绪

解析后,这些信息会自动分配到对应的生成任务。

角色一致性系统

这个很重要。

同一个角色在不同分镜中必须保持一致:

• 服装
• 发型
• 妆容
• 道具

系统通过 Character Bible 管理这些约束。

绑定角色参考图,确保一致性。

场景生成:多视角联合图

AI 可以生成多视角的场景描述图。

比如,角色 A 从左看场景,角色 B 从右看。

这些描述图会自动转换为视觉提示词,指导视频生成。

导演分镜系统

电影级摄影参数:

• 景别
• 机位
• 运动方式

自动排版和导出。

视觉风格一键切换:

• 2D
• 3D
• 写实
• 定格动画

Seedance 2.0 参数约束

Seedance 2.0 有参数限制。

自动校验:

• 图片 ≤9 张
• 视频 ≤3 个
• 音频 ≤3 个
• prompt ≤5000 字

超过就自动拒绝或截断。

好处:

• 避免超成本
• 保证 API 调用效率

批量化生产工作流

多任务并行队列:

• 自动重试失败任务
• 任务优先级管理
• 进度追踪

适合:

• 短剧批量生产
• 动漫番剧批量制作
• 预告片批量生成

技术架构

前端技术

这个技术栈很现代,开发体验应该不错。

后端核心

@opencut/ai-core 是 AI 核心引擎。

主要功能:

• Prompt 编译
• 角色圣经管理
• 任务轮询管理
• 多供应商 API 集成

这是整个系统的大脑。

项目结构

1
2
3
4
5
6
7
8
9
10
11

moyin-creator/
├── electron/              # Electron 主进程
│   ├── main.ts           # 主进程入口
│   └── preload.ts        # 安全桥接层
├── src/                   # React 前端源码
│   ├── components/       # UI 组件
│   │   ├── panels/      # 功能面板
│   │   ├── stores/       # 状态管理
│   └── packages/        # 内部包
│       └── ai-core/      # AI 核心引擎
└── scripts/              # 构建脚本

结构清晰,模块化做得不错。

使用流程

环境要求

• Node.js >= 18
• npm >= 9
• 支持 Windows, macOS, Linux

安装运行

1
2
3
4
5
6
7
8
9

# 克隆项目
git clone https://github.com/MemeCalculate/moyin-creator.git
cd moyin-creator

# 安装依赖
npm install

# 启动开发模式
npm run dev

配置 API Key

首次启动后进入设置页面。

配置你的 AI 服务商 API Key:

• OpenAI
• Anthropic
• Google
• 或者其他兼容的 API

配置好后就可以开始使用了。

使用场景

场景一:短剧批量生产

1. 上传剧本文件
2. 系统自动解析剧本
3. 生成角色和场景
4. 批量生成视频片段
5. 自动剪辑和配乐
6. 导出成品

适合自媒体工作室,短视频创业公司。

场景二:预告片制作

1. 写剧本或用 AI 生成
2. 设定分镜脚本
3. 生成高质量场景图
4. 生成预告片视频
5. 配音和后期处理

适合影视工作室,内容创作团队。

场景三:广告视频批量化

1. 设定广告脚本
2. 批量生成多个变体
3. A/B 测试不同版本
4. 自动分析数据,选择最优方案
5. 批量导出和分发

适合广告公司,电商营销团队。

优势分析

相比传统方式

实际使用建议

1. 先从小规模开始

不要一上来就想批量生产几百个视频。

建议:

• 从一个 5-10 分钟的短剧开始
• 熟悉工具和工作流
• 找到问题和优化点
• 再逐步扩大规模

2. 重视剧本质量

AI 再强大,也需要好的剧本。

建议:

• 简单但有趣的故事
• 明确的角色设定
• 清晰的场景描述
• 合理的分镜节奏

好的剧本是成功的一半。

3. 合理使用 Seedance 2.0

Seedance 2.0 是当前最强的视频生成模型,但成本也高。

建议:

• 短视频用 Seedance 2.0
• 长视频用其他模型
• 混合使用,控制成本
• 实时预览,减少重试次数

4. 注意参数约束

Seedance 2.0 的参数限制是硬约束,不是建议。

违反的话:

• 直接被 API 拒绝
• 任务失败
• 浪费成本

一定要在约束范围内使用。

5. 建立内容标准

批量生产时,质量更重要。

建议:

• 统一角色设定
• 统一视觉风格
• 统一音频标准
• 定期审核和优化

网络上的实践案例

短剧生产

有个博主分享了 moyin-creator 的使用流程:

1. 用 GPT-4 写剧本
2. 导入 moyin-creator 解析剧本
3. 配置 5 个角色
4. 批量生成 100 个视频
5. 用剪映自动剪辑
6. 发布后批量上传

一周生产了 100 个短剧,效率提升明显。

预告片制作

另一个工作室用 moyin-creator:

1. 写了 10 个预告片剧本
2. 用 Seedance 2.0 生成高质量场景图
3. 用 Kling 生成预告片视频
4. 批量配音和后期处理
5. 一周内完成 10 个预告片

效率比传统方式提升了 10 倍以上。

商业广告批量化

广告公司用它:

1. 批量生成 20 个产品广告
2. 每个广告 5 个版本
3. A/B 测试不同文案和视觉效果
4. 自动分析数据,选择最优方案
5. 批量导出和分发

广告投放效果提升了 35%。

未来趋势

AI 视频生成的趋势

1. 多模态融合

   • 文本 + 图像 + 音频 + 视频
   • 模型越来越强,成本越来越低
   • moyin-creator 的架构可以快速集成新模式

2. 实时生成

   • 实时预览和调整
   • 减少重试次数
   • 提升用户满意度

3. 个性化定制

   • 基于用户数据的模型微调
   • 风格一致性系统
   • 自动化质量检查

4. 自动化工作流

   • 更多环节自动化
   • 减少人工干预
   • 提升整体效率

moyin-creator 的机会

优势

1. 完整的产业链覆盖

   • 从剧本到成片的完整工作流
   • 不是单一工具,是平台级解决方案

2. 模块化架构

   • 各个板块可以独立优化
   • 便于扩展和维护

3. 多供应商支持

   • 不绑定单一 AI 服务商
   • 用户有更多选择和议价权

4. 开源可定制

   • 技术栈公开
   • 商业许可证可选
   • 可以二次开发和定制

潜在挑战

1. 竞争激烈

   • Midjourney, Runway, Kling 都在快速迭代
   • moyin-creator 需要持续创新

2. 成本压力

   • Seedance 2.0 等模型的成本很高
   • 用户需要控制预算

3. 质量平衡

   • 追求效率可能影响质量
   • 需要找到平衡点

4. 用户习惯

   • 传统创作团队有固定工作流
   • 工具需要适应不同团队

给不同用户的建议

内容创作者

如果你想尝试 moyin-creator:

1. 先评估需求

   • 你需要批量生产吗?
   • 预算规模和成本
   • 团队有技术能力自己部署吗?

2. 从小规模实验

   • 不要一上来就大规模投入
   • 先做几个小项目验证效果
   • 熟悉工作流后再扩大

3. 重视内容质量

   • 剧本是基础,多花时间打磨
   • 角色和场景设计要有吸引力
   • 不要因为批量生成就忽视质量

4. 合理选择模型

   • Seedance 2.0 用于高质量场景
   • 其他模型用于普通内容
   • 混合使用,控制成本

开发者

如果你想学习 moyin-creator 的技术实现:

1. 研究技术架构

   • Electron + React 技术栈
   • Zustand 状态管理
   • 模块化设计

2. 学习 AI 集成

   • 如何设计 AI 核心
   • 如何实现多供应商支持
   • 如何设计任务队列

3. 学习视频处理

   • FFmpeg 集成
   • 视频编码和优化
   • 批量处理优化

4. 考虑贡献代码

   • 开源项目需要社区贡献
   • 可以提 issue 或提 PR

企业用户

如果你考虑在企业中使用:

1. 评估 ROI

   • 效率提升 vs 工具成本
   • 削减和人力成本节省
   • 投资回报周期

2. 数据安全

   • 本地部署 vs 云端部署
   • API Key 安全管理
   • 用户数据保护

3. 团队培训

   • 工作流培训
   • 最佳实践分享
   • 持续优化和改进

写在最后

moyin-creator 代表了 AI 视频生成工具的一个方向:生产级工作流自动化。

它不是一个”黑科技”,而是一套实用的工程化解决方案。

它的价值不在于用了什么先进技术,而在于:

• 完整的产业链覆盖
• 高效的批量生产能力
• 好的质量控制
• 合理的成本控制

适合内容创作者、影视工作室、广告公司,或者任何需要批量生产视频内容的团队。

但也要理性看待:

• 不要被”批量生产”迷惑
• 质量仍然是核心竞争力
• 工具是辅助,不是替代人的创造力

找到自己的节奏,持续优化,才是王道。

参考

• 项目地址: https://github.com/MemeCalculate/moyin-creator
• 中文文档: https://www.bilibili.com/video/BV1FsZDBHExJ/?vd_source=802462c0708e775ce81f95b2e486f175
• 网盘提取码: 8888

📢 更新日志：

• 2026-03-09 补充 HEARTBEAT.md 抢占主会话的排障记录，修正文中 Docker Compose 版本与记忆机制描述，新增“升级是否成功”的核验方法。
• 2026-03-06 新增 Step-3.5-Flash 接入与会话级 /model 切换说明，补充默认模型不切全局、只切当前会话的使用方式。
• 2026-03-03 新增”记录系统优化”章节，解决会话文件膨胀问题，添加自动归档和结构化存储方案。

写在前面

最近刷到不少 OpenClaw 的文章，演示零成本安装、智能体集群、国内部署经验。我手头正好有台配置不高的云服务器闲置着，决定动手搭建一个专属 AI 助手。

但这篇文章不是推广，是真实的部署踩坑记录。整个过程历时数小时，遇到了 OOM 内存不足、配置验证失败、防火墙规则冲突等一系列问题，把完整的解决过程记录下来。

先说结论：OpenClaw 确实能跑起来，但需要对 Docker、网络和 Linux 有一定了解，且内存配置要充足。

OpenClaw 是什么

OpenClaw 是一个开源的个人 AI 助手框架，核心价值在于：它不是只聊天的 AI，而是能动手干活的 AI。

核心能力：

• 在 Telegram、Discord、Slack 等平台接收指令
• 操作文件系统、执行 Shell 命令、浏览网页
• 调用 API、读写数据库
• 跨会话持久化记忆

最重要的是——运行在自己的服务器上，数据完全掌控。

我的环境

搬瓦工买的一台机器，配置不高，平时捣鼓各种东西的。

⚠️ 重要提示：2GB 内存对于源码构建来说不够，需要配置 Swap。

部署过程实录

第一步：安装 Docker

Ubuntu 24.04 下安装 Docker 很顺利：

1
2
3
4
5
6
7
8
9

# 更新系统
apt update && apt upgrade -y

# 安装 Docker
curl -fsSL https://get.docker.com | sh

# 验证安装
docker --version  # Docker version 29.2.1
docker compose version  # Docker Compose version v5.1.0

国内用户建议配置镜像加速，编辑 /etc/docker/daemon.json：

1
2
3
4
5
6

{
  "registry-mirrors": [
    "https://docker.1ms.run",
    "https://dockerhub.icu"
  ]
}

第二步：源码构建（第一个坑：OOM）

官方提供了 Docker 镜像，但我选择从源码构建以获得最新功能：

1
2
3
4

mkdir -p /opt/openclaw
cd /opt/openclaw
git clone https://github.com/openclaw/openclaw.git
cd openclaw

开始构建：

1

docker build -t openclaw:local -f Dockerfile .

🚨 第一个大坑：构建到 pnpm install 时容器被杀

查看日志发现是 OOM（内存不足）。2GB RAM 在构建 Node.js 项目时不够用，pnpm install 直接占满内存导致进程被系统杀死。

解决方案：添加 Swap 空间

1
2
3
4
5
6
7
8
9

# 创建 5GB Swap 文件
dd if=/dev/zero of=/swapfile bs=1G count=5
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# 验证
free -h
# 显示：Swap: 5.0Gi

添加 Swap 后重新构建，成功完成。

📷 安装过程 - 添加 Swap 解决 OOM：

第三步：配置 OpenClaw

创建 docker-compose.yml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

version: '3.8'

services:
  openclaw-gateway:
    image: openclaw:local
    container_name: openclaw
    restart: unless-stopped
    environment:
      - HOME=/home/node
      - NODE_ENV=production
    volumes:
      - ./.openclaw:/home/node/.openclaw
      - ./.openclaw/workspace:/home/node/.openclaw/workspace
    ports:
      - "127.0.0.1:18789:18789"
      - "127.0.0.1:18790:18790"
    command: ["node", "dist/index.js", "gateway", "--bind", "lan", "--port", "18789"]

🚨 第二个坑：配置验证极其严格

OpenClaw 对 openclaw.json 配置文件的校验非常严格，很多字段在官方文档中没有明确说明，但缺失会导致启动失败。

我遇到的错误：

1
2
3

✖ Configuration validation failed:
  - gateway.mode is required
  - gateway.controlUi.allowedOrigins is required when using non-loopback bind

正确的最小配置（openclaw.json）：

1
2
3
4
5
6
7
8
9
10
11
12

{
  "gateway": {
    "port": 18789,
    "mode": "local",
    "controlUi": {
      "allowedOrigins": ["http://localhost:18789", "http://127.0.0.1:18789"]
    },
    "auth": {
      "token": "your-secure-token-here"
    }
  }
}

📷 OpenClaw Web UI 界面：

关键注意点：

• gateway.mode 必须显式设置为 "local"
• gateway.controlUi.allowedOrigins 在使用非 localhost 绑定时是必需的
• gateway.bind 不能写在 JSON 中（无效字段），必须通过 CLI 参数 --bind lan 设置

第四步：配置阿里云百炼模型

我选择使用阿里云百炼的 Coding Plan，配置 kimi-k2.5 作为主力模型：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

{
  "models": {
    "mode": "merge",
    "providers": {
      "bailian": {
        "baseUrl": "https://coding.dashscope.aliyuncs.com/v1",
        "apiKey": "YOUR_BAILIAN_API_KEY",
        "api": "openai-completions",
        "models": [
          {
            "id": "kimi-k2.5",
            "name": "kimi-k2.5",
            "input": ["text", "image"],
            "contextWindow": 262144,
            "maxTokens": 32768
          },
          {
            "id": "qwen3.5-plus",
            "name": "qwen3.5-plus",
            "input": ["text", "image"],
            "contextWindow": 1000000,
            "maxTokens": 65536
          }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "bailian/kimi-k2.5"
      }
    }
  }
}

第五步：配置 Telegram Bot

在 @BotFather 创建 Bot 并获取 Token。

🚨 第三个坑：配对码过期与 dmPolicy 冲突

1
2
3
4
5
6
7
8
9

{
  "channels": {
    "telegram": {
      "enabled": true,
      "botToken": "YOUR_BOT_TOKEN_HERE",
      "allowFrom": ["YOUR_TELEGRAM_USER_ID"]
    }
  }
}

初始配置时我加了 "dmPolicy": "open"，结果与 allowFrom 白名单冲突，报错：

1

dmPolicy: open requires allowFrom: ["*"]

解决方案：删除 dmPolicy 字段，直接使用 allowFrom 白名单。

启动服务：

1
2

docker compose up -d
docker compose logs -f

看到日志显示 Telegram channel started 且没有错误，说明 Bot 已上线。

📷 Telegram Bot 配置成功：

第六步：Google Workspace 集成（扩展能力）

这是 OpenClaw 真正强大的地方——通过 Google Workspace 集成，AI 可以帮你管理邮件、日历、文档。

OpenClaw 使用 gog skill 来访问 Google 服务（Gmail、Calendar、Drive、Docs、Sheets）。

6.1 创建 Google Cloud 项目

1. 访问 Google Cloud Console
2. 创建新项目（例如：openclaw-integration）
3. 启用以下 API：
   • Gmail API
   • Google Calendar API
   • Google Drive API
   • Google Docs API
   • Google Sheets API

6.2 配置 OAuth 凭据

1. 进入 APIs & Services > Credentials
2. 点击 Create Credentials > OAuth client ID
3. 选择 Desktop app 类型
4. 记下 Client ID 和 Client Secret

6.3 配置 MCP 服务器

OpenClaw 通过 MCP (Model Context Protocol) 集成 Google Workspace。

在服务器上创建 MCP 配置文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

mkdir -p /opt/openclaw/.openclaw/mcp
cat > /opt/openclaw/.openclaw/mcp/google-workspace.json << 'EOF'
{
  "mcpServers": {
    "google-workspace": {
      "command": "npx",
      "args": ["-y", "@gongchangio/mcp-google-workspace"],
      "env": {
        "GOOGLE_CLIENT_ID": "your-client-id.apps.googleusercontent.com",
        "GOOGLE_CLIENT_SECRET": "your-client-secret",
        "GOOGLE_REDIRECT_URI": "http://localhost:18790/oauth2callback"
      }
    }
  }
}
EOF

6.4 重启 OpenClaw 并授权

1
2
3
4
5

cd /opt/openclaw
docker compose restart

# 查看日志等待授权提示
docker compose logs -f | grep -i google

首次启动会显示 OAuth 授权链接，在浏览器中打开并授权后，会获得一个 code，将其填回即可。

6.5 实际使用场景

配置完成后，你可以通过 Telegram 让 AI 帮你：

管理邮件：

“帮我查看今天的重要邮件，并回复需要处理的”

操作日历：

“帮我查一下下周的会议安排，把周五下午的会议改到周四”

读写文档：

“读取 Drive 里的 ‘项目计划.docx’，帮我总结要点并更新状态”

⚠️ 注意：Google OAuth 有权限范围限制

• 个人 Gmail 账户：直接可用
• Google Workspace（企业账户）：需要管理员授权
• 敏感范围（如删除邮件）需要额外验证

第七步：安全加固（重中之重）

🚨 第四个坑：Docker 绕过 INPUT 链的防火墙规则

我最初的防火墙配置：

1
2

iptables -I INPUT 1 -p tcp --dport 18789 -s 127.0.0.1 -j ACCEPT
iptables -I INPUT 2 -p tcp --dport 18789 -j DROP

测试发现：公网仍然可以访问 Web UI！

原因：Docker 在 DOCKER 链中插入了 ACCEPT 规则，且该链在 INPUT 链之前被处理。

正确的解决方案：使用 DOCKER-USER 链

1
2
3
4
5
6
7
8

# 在 DOCKER-USER 链中插入规则（在 Docker 规则之前执行）
iptables -I DOCKER-USER 1 -p tcp -s 127.0.0.1 --dport 18789 -j ACCEPT
iptables -I DOCKER-USER 2 -p tcp --dport 18789 -j DROP
iptables -I DOCKER-USER 3 -p tcp -s 127.0.0.1 --dport 18790 -j ACCEPT
iptables -I DOCKER-USER 4 -p tcp --dport 18790 -j DROP

# 保存规则
iptables-save > /root/iptables-rules.txt

最终安全策略：

📷 最后安全检查 - 安全加固结果：

SSH 隧道访问命令：

1
2

ssh -N -L 18789:127.0.0.1:18789 root@your-server-ip
# 然后在本地浏览器访问 http://localhost:18789

进阶玩法：持久记忆配置（第9步）

OpenClaw 的持久记忆系统让它能跨会话记住你的偏好、项目信息和个人习惯。这是从”工具”升级为”助手”的关键。

记忆文件目录结构

核心记忆文件

1. USER.md - 用户档案

1
2
3
4
5
6
7
8
9
10

# USER.md - About Your Human

- **Name:** Gamehu
- **What to call them:** Gamehu
- **Timezone:** Asia/Shanghai (UTC+8)

## Context
- **职业:** IT 行业，编程 + 团队管理
- **需求:** 个人助手
- **风格偏好:** 简单直接，不绕弯子

2. MEMORY.md - 长期记忆

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# MEMORY.md - Long-term Memory

## Technical Stack
- **Primary Languages:** Java, JavaScript, Python, Go
- **Frameworks:** Spring Boot, React
- **Cloud:** Alibaba Cloud, AWS

### Preferences
- **Code Style:** Clean, well-documented
- **Learning Style:** Hands-on, project-based
- **Dislikes:** Repetitive small talk

### Current Projects
- Building personal AI assistant
- Managing development team

如何工作

1. 自动记忆：所有对话自动存入 SQLite，跨会话保持上下文
2. 结构化记忆：AI 主动读取 MEMORY.md 了解你的背景和偏好
3. 持续更新：OpenClaw 可以通过 heartbeat 或维护任务定期整理记忆，但主会话不建议配置成高频主动提醒模式

测试持久记忆

给 Bot 发送：

“记住我喜欢用 Go 语言写后端服务”

过一段时间再问：

“我之前告诉你我喜欢用什么语言？”

如果配置正确，Bot 应该能回答出 Go。

进阶玩法：记录系统优化（第9.5步，新增）

在解决 compaction 卡死问题后，我意识到 OpenClaw 的会话记录管理还有很多优化空间。之前的经历是：会话文件在两天内膨胀到 1.4MB（603 条消息），导致系统卡死。为了防止类似问题再次发生，我设计并部署了一套结构化的记录管理系统。

为什么需要记录系统优化

优化后的目录结构

我在 workspace 下创建了完整的分类存储结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

/root/.openclaw/workspace/
├── memory/                    # 记忆类数据
│   ├── daily/                # 每日摘要 (YYYY-MM-DD.md)
│   ├── weekly/               # 每周汇总
│   └── archived/             # 长期归档
├── records/                   # 记录类数据
│   ├── conversations/        # 对话记录 (按月归档)
│   │   └── 2026-03/
│   │       ├── 2026-03-03/   # 当日完整会话
│   │       └── 2026-03-03-sessions.tar.gz
│   ├── tasks/                # 任务记录
│   │   ├── completed/        # 已完成任务
│   │   └── failed/           # 失败任务
│   ├── browser/              # 浏览器操作记录
│   │   ├── screenshots/      # 网页截图
│   │   └── page-dumps/       # 页面快照
│   └── files/                # 文件操作日志
├── outputs/                   # 输出类数据
│   ├── generated/            # AI 生成的文档
│   ├── exports/              # 导出文件
│   └── reports/              # 定时报告
└── logs/                      # 日志类
    ├── system/               # 系统日志 (archive-YYYY-MM-DD.log)
    ├── model/                # 模型调用记录
    └── errors/               # 错误日志

自动归档脚本

创建 /root/.openclaw/workspace/archive-daily.sh：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

#!/bin/bash
WORKSPACE="/root/.openclaw/workspace"
SESSIONS_DIR="/home/node/.openclaw/agents/main/sessions"
DATE=$(date +"%Y-%m-%d")
MONTH=$(date +"%Y-%m")

# 创建归档目录
mkdir -p "$WORKSPACE/records/conversations/$MONTH/$DATE"
mkdir -p "$WORKSPACE/memory/daily"

# 归档会话文件
if [ -d "$SESSIONS_DIR" ]; then
    cp "$SESSIONS_DIR"/*.jsonl "$WORKSPACE/records/conversations/$MONTH/$DATE/" 2>/dev/null || true
    SESSION_COUNT=$(ls -1 "$SESSIONS_DIR"/*.jsonl 2>/dev/null | wc -l)
    SIZE=$(du -sb "$SESSIONS_DIR" 2>/dev/null | cut -f1)
else
    SESSION_COUNT=0
    SIZE=0
fi

# 生成每日摘要 Markdown
cat > "$WORKSPACE/memory/daily/${DATE}.md" << DAILYMD
---
date: ${DATE}
type: daily-summary
sessions_count: ${SESSION_COUNT}
sessions_size_kb: $((${SIZE} / 1024))
---

# 📅 ${DATE} 对话摘要

## 📊 今日统计
- **日期**: ${DATE}
- **星期**: $(date +%A)
- **会话数**: ${SESSION_COUNT}
- **数据大小**: $((${SIZE} / 1024)) KB

## 🏷️ 重要标签
- 

## 💡 今日收获
- 

## 📌 待办事项
- [ ] 

---
DAILYMD

# 记录归档日志
echo "[$(date)] 归档完成: ${DATE}, ${SESSION_COUNT} 个会话" >> "$WORKSPACE/logs/system/archive-${DATE}.log"

赋予执行权限：

1

chmod +x /root/.openclaw/workspace/archive-daily.sh

配置定时任务

添加每天 23:00 自动执行归档：

1
2
3
4
5

# 添加定时任务
(crontab -l 2>/dev/null | grep -v archive-daily; echo "0 23 * * * /root/.openclaw/workspace/archive-daily.sh >> /root/.openclaw/workspace/logs/system/cron.log 2>&1") | crontab -

# 查看已配置的定时任务
crontab -l

快捷命令配置

创建 /root/.openclaw/.aliases.sh，方便快速查看记录：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 查看今日记录
alias oc-today='cat /root/.openclaw/workspace/memory/daily/$(date +%Y-%m-%d).md 2>/dev/null || echo "今日记录不存在"'

# 查看昨日记录
alias oc-yesterday='cat /root/.openclaw/workspace/memory/daily/$(date -d yesterday +%Y-%m-%d 2>/dev/null || date -v-1d +%Y-%m-%d).md 2>/dev/null || echo "昨日记录不存在"'

# 手动执行归档
alias oc-archive='/root/.openclaw/workspace/archive-daily.sh'

# 查看统计
alias oc-stats='echo "=== OpenClaw 统计 ===" && echo "会话文件: $(ls -1 /home/node/.openclaw/agents/main/sessions/*.jsonl 2>/dev/null | wc -l)" && echo "每日摘要: $(ls -1 /root/.openclaw/workspace/memory/daily/*.md 2>/dev/null | wc -l)"'

# 查看目录大小
alias oc-size='du -sh /root/.openclaw/workspace/*/ 2>/dev/null | sort -h'

使用方法：

1
2
3
4
5
6
7
8
9
10
11

# 加载快捷命令
source /root/.openclaw/.aliases.sh

# 查看今日记录
oc-today

# 手动归档
oc-archive

# 查看统计
oc-stats

Docker 容器内配置

为了让 OpenClaw Bot 也能执行归档，在 Docker 容器内创建归档脚本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

# 在容器内创建归档命令
docker exec openclaw-openclaw-gateway-1 bash -c 'cat > /tmp/oc-archive.sh << "EOF"
#!/bin/bash
WORKSPACE="/home/node/.openclaw/workspace"
SESSIONS="/home/node/.openclaw/agents/main/sessions"
DATE=$(date +"%Y-%m-%d")
MONTH=$(date +"%Y-%m")
mkdir -p "$WORKSPACE/records/conversations/$MONTH/$DATE"
COUNT=0
if [ -d "$SESSIONS" ]; then
  cp "$SESSIONS"/*.jsonl "$WORKSPACE/records/conversations/$MONTH/$DATE/" 2>/dev/null || true
  COUNT=$(ls -1 "$SESSIONS"/*.jsonl 2>/dev/null | wc -l)
fi
cat > "$WORKSPACE/memory/daily/$DATE.md" << DAILY
---
date: $DATE
type: daily-summary
sessions_count: $COUNT
---

# 📅 $DATE 对话摘要

## 📊 统计
- 会话数: $COUNT

## 🏷️ 标签
- 

## 💡 收获
- 
DAILY
echo "✅ 归档完成: $DATE, $COUNT 个会话"
EOF
chmod +x /tmp/oc-archive.sh'

Telegram Bot 使用

配置完成后，你可以直接在 Telegram 中对 Bot 发送：

每日摘要示例

生成的 Markdown 文件 (memory/daily/2026-03-03.md)：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

---
date: 2026-03-03
type: daily-summary
sessions_count: 5
sessions_size_kb: 45
---

# 📅 2026-03-03 对话摘要

## 📊 今日统计
- **日期**: 2026-03-03
- **星期**: Tuesday
- **会话数**: 5
- **数据大小**: 45 KB

## 🏷️ 重要标签
- OpenClaw 配置
- 技能开发

## 💡 今日收获
- 配置了自动归档系统
- 解决了会话文件膨胀问题

## 📌 待办事项
- [ ] 测试归档功能
- [ ] 配置 Web 画廊

这种结构化的记录管理方式，让你可以：

1. 快速回顾 - 每天打开 Markdown 文件即可看到当日概况
2. 防止膨胀 - 自动归档避免会话文件无限增长
3. 便于导出 - 重要记录可以轻松导出分享
4. Telegram 管理 - 直接通过 Bot 指令管理记录

进阶玩法：自定义 Skill（第10步）

OpenClaw 的 Skill 系统让你可以扩展 AI 的能力。我把自己的 Hexo 博客做成了 Skill，让 Bot 可以直接帮我创建博客文章。

我的 Hexo 博客 Skill

1. 创建脚本

在服务器上创建文章生成脚本 /opt/hexo-blog/create-post.sh：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

#!/bin/bash
# Hexo Blog Post Creator

BLOG_DIR="/opt/hexo-blog"
POSTS_DIR="$BLOG_DIR/source/_posts"

# 参数
TITLE="${1:-新建文章}"
CATEGORY="${2:-随笔}"
TAGS="${3:-日常}"
DATE=$(date +"%Y-%m-%d %H:%M:%S")
FILENAME=$(echo "$TITLE" | sed 's/ /-/g' | tr '[:upper:]' '[:lower:]')-$(date +"%Y%m%d").md

# 创建目录
mkdir -p "$POSTS_DIR"

# 创建文章
cat > "$POSTS_DIR/$FILENAME" << EOF
---
title: $TITLE
author: Gamehu
date: $DATE
tags:
EOF

# 添加标签
IFS=',' read -ra TAG_ARRAY <<< "$TAGS"
for tag in "${TAG_ARRAY[@]}"; do
    echo "  - $(echo $tag | xargs)" >> "$POSTS_DIR/$FILENAME"
done

# 添加分类和正文
cat >> "$POSTS_DIR/$FILENAME" << EOF
categories:
  - $CATEGORY
---

## 写在前面

$TITLE

<!-- more -->

## 正文

开始写作...

---
EOF

echo "✅ 文章创建成功: $POSTS_DIR/$FILENAME"

赋予执行权限：

1

chmod +x /opt/hexo-blog/create-post.sh

2. 创建 Skill 文件

OpenClaw 使用 SKILL.md 文件（不是 YAML），创建 ~/.openclaw/skills/hexo-blog/SKILL.md：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

---
name: hexo-blog
description: Create and manage Hexo blog posts via shell script
---

# Hexo Blog Skill

Create new blog posts with proper front matter for Hexo.

## Usage

Ask me to create a blog post:
- "帮我创建一篇博客文章，标题是《XXX》，分类是技术，标签是 OpenClaw,AI"
- "写一篇新文章，关于 Docker 使用心得"

## Tools

This skill uses the `shell` tool to execute `/opt/hexo-blog/create-post.sh`.

## Example

```bash
/opt/hexo-blog/create-post.sh "文章标题" "分类" "标签1,标签2"

1
2
3
4
5

#### 3. 重启 OpenClaw 加载 Skill

```bash
docker restart openclaw-openclaw-gateway-1

验证 Skill 是否加载：

1
2

openclaw skills list
# 应该显示: ✓ ready │ 📦 hexo-blog │ Create and manage Hexo blog posts...

3. 实际使用

在 @gamehu_kb_bot 里直接说：

“帮我创建一篇博客文章，标题是《OpenClaw 使用心得》，分类是工具，标签是 OpenClaw,AI”

Bot 会自动：

1. 生成文件名 openclaw-shi-yong-xin-de-20260302.md
2. 创建带完整 Front Matter 的 Markdown 文件
3. 返回文件路径

Skill 核心概念

更多 Skill 想法

• Git Helper: 自动提交、查看状态、创建分支
• Docker Manager: 查看容器日志、重启服务
• File Organizer: 整理下载文件夹、重命名文件
• Daily Reporter: 生成每日工作总结

进阶玩法：浏览器控制（第12步）

OpenClaw 内置了浏览器控制功能，让 AI 能够操作真实浏览器执行网页任务，比如搜索信息、填写表单、抓取数据等。

🚨 坑位 14：Docker 镜像默认不包含浏览器

问题

Docker 部署后尝试使用浏览器功能时，报错：

1
2

[tools] browser failed: Error: No supported browser found 
(Chrome/Brave/Edge/Chromium on macOS, Linux, or Windows).

原因

默认的 Dockerfile 不会安装 Chromium/Playwright 浏览器，需要通过 --build-arg OPENCLAW_INSTALL_BROWSER=1 参数构建带浏览器的镜像。

解决方案：重新构建带浏览器的镜像

1. 停止当前服务

1
2

cd /opt/openclaw
docker compose down

2. 构建带浏览器的新镜像

1
2
3
4
5

# 构建时间约 15-30 分钟，增加约 300MB
docker build -t openclaw:local-browser -f Dockerfile \
  --build-arg OPENCLAW_INSTALL_BROWSER=1 \
  --build-arg OPENCLAW_DOCKER_APT_PACKAGES="chromium xvfb" \
  .

3. 修改环境变量使用新镜像

编辑 .env 文件：

1
2
3
4
5

# 修改前
OPENCLAW_IMAGE=openclaw:local

# 修改后
OPENCLAW_IMAGE=openclaw:local-browser

4. 启动服务

1

docker compose up -d

5. 验证浏览器安装

1
2
3
4
5
6
7
8

# 进入容器检查
docker exec openclaw-openclaw-gateway-1 \
  ls -la /home/node/.cache/ms-playwright/

# 应该看到：
# chromium-1208/
# chromium_headless_shell-1208/
# ffmpeg-1011/

浏览器控制功能

使用示例

在 Telegram 中直接发送以下指令：

搜索信息：

“打开浏览器，访问 GitHub，搜索 ‘openclaw’，告诉我前 3 个结果”

商品比价：

“帮我在京东上搜索 ‘机械键盘’，找到评分最高的 3 个产品，记录价格”

数据抓取：

“访问 https://news.ycombinator.com/，提取首页前 10 条新闻的标题和链接”

浏览器控制原理

1

用户指令 → OpenClaw Agent → 浏览器控制服务 → 无头 Chrome → 网页操作 → 结果返回

浏览器控制服务默认监听：http://127.0.0.1:18791/

注意事项

1. 无头模式：Docker 部署默认使用 headless 模式（无界面），适合服务器环境
2. 访问限制：受限于服务器网络，无法访问需要登录的页面（除非提供 Cookie）
3. 执行时间：复杂页面加载可能需要 10-30 秒
4. 安全提醒：避免让 Bot 访问敏感网站或输入真实账号密码

实践任务

尝试让 Bot 完成以下任务：

• ✅ 信息收集：从某个网站抓取数据并整理
• ✅ 表单填写：自动填写一个在线表单
• ✅ 价格比较：在多个网站比较同一商品的价格

进阶玩法：多 Bot 配置（第11步）

OpenClaw 支持配置多个 Telegram Bot，每个 Bot 可以绑定不同的 Agent，实现分工协作。
注意：仅配置 channels.telegram.accounts 还不够，想要真正隔离上下文，必须再加 agents.list + bindings。

我的多 Bot 架构

配置步骤

1. 在 @BotFather 创建多个 Bot

每个 Bot 都需要独立的 Token：

1
2
3
4

/main_bot - 主助手
/news_bot - 新闻助手  
/growth_bot - 成长助手
/kb_bot - 知识库助手

2. 配置多账号

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

{
  "channels": {
    "telegram": {
      "enabled": true,
      "accounts": {
        "main": {
          "botToken": "YOUR_MAIN_BOT_TOKEN",
          "allowFrom": ["YOUR_TELEGRAM_USER_ID"]
        },
        "news": {
          "botToken": "YOUR_NEWS_BOT_TOKEN",
          "allowFrom": ["YOUR_TELEGRAM_USER_ID"]
        },
        "growth": {
          "botToken": "YOUR_GROWTH_BOT_TOKEN",
          "allowFrom": ["YOUR_TELEGRAM_USER_ID"]
        },
        "kb": {
          "botToken": "YOUR_KB_BOT_TOKEN",
          "allowFrom": ["YOUR_TELEGRAM_USER_ID"]
        }
      }
    }
  }
}

3. 增加 Agent 路由绑定（关键）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "agents": {
    "list": [
      { "id": "main",   "default": true, "workspace": "/home/node/.openclaw/workspace" },
      { "id": "news",   "workspace": "/home/node/.openclaw/workspace-news" },
      { "id": "growth", "workspace": "/home/node/.openclaw/workspace-growth" },
      { "id": "kb",     "workspace": "/home/node/.openclaw/workspace-kb" }
    ]
  },
  "bindings": [
    { "agentId": "main",   "match": { "channel": "telegram", "accountId": "main" } },
    { "agentId": "news",   "match": { "channel": "telegram", "accountId": "news" } },
    { "agentId": "growth", "match": { "channel": "telegram", "accountId": "growth" } },
    { "agentId": "kb",     "match": { "channel": "telegram", "accountId": "kb" } }
  ]
}

⚠️ workspace 字段必须显式指定：每个 agent 需要独立的 workspace 路径，否则多个 agent 共享同一个 workspace，记忆和配置会互相干扰。

这样每个 bot 会落到不同 agent，会话文件分目录保存，记忆文件也完全隔离。

4. 为每个 Agent 创建独立 Workspace

每个 agent 对应一个独立目录，在服务器上创建：

1
2
3

mkdir -p /root/.openclaw/workspace-news
mkdir -p /root/.openclaw/workspace-growth
mkdir -p /root/.openclaw/workspace-kb

每个目录下的结构：

1
2
3
4
5
6

workspace-news/
├── SOUL.md        # Agent 的身份定义
├── MEMORY.md      # 长期记忆
├── USER.md        # 用户信息
├── AGENTS.md      # Agent 行为规范
└── memory/        # 每日记忆文件

每个 AGENT.md 定义该 Bot 的专业领域和行为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# News Agent

## Role
你是一个科技新闻助手，专注于提供最新、最有价值的科技资讯。

## Capabilities
- 追踪科技行业动态
- 总结技术文章要点
- 提供每日新闻简报

## Style
- 简洁明了，重点突出
- 提供信息来源链接
- 主动推送重要消息

4. 重启服务

1

docker compose restart

查看日志确认所有 Bot 启动：

1
2
3
4

[telegram] [main] starting provider (@GameHuOpenclaw_bot)
[telegram] [news] starting provider (@gamehu_news_bot)
[telegram] [growth] starting provider (@gamehu_growth_bot)
[telegram] [kb] starting provider (@gamehu_kb_bot)

实际使用效果

• 上下文隔离：在 @gamehu_growth_bot 聊学习计划，切到 @gamehu_news_bot 问新闻，再回到 growth Bot，它还记得刚才的学习话题
• 专业化分工：每个 Bot 专注于自己的领域，回复质量更高
• 并行对话：可以同时和多个 Bot 对话，互不干扰

⚠️ 注意事项

• 多账号配置时，不要在顶层设置 botToken，全部放在 accounts 下
• 每个 accountId（如 main、news、growth、kb）必须是唯一的
• 账号名不要用 default，会和系统默认账号冲突

进阶玩法：定时任务推送到指定 Bot（第11.5步）

配置好多 Bot 之后，你可能会发现一个问题：OpenClaw 里设置的定时任务（cron job），推送结果全都跑到了 main bot，而不是对应的 bot。

🚨 坑位 17：定时任务 delivery 缺少 accountId

问题现象

在 OpenClaw Web UI 里配了新闻推送任务，时间一到，消息却出现在了 @GameHuOpenclaw_bot（main bot），而不是 @gamehu_news_bot。

根本原因

OpenClaw 的定时任务存储在 ~/.openclaw/cron/jobs.json，每个任务的 delivery 字段控制推送目标。如果只写了 to（用户 ID），没有写 accountId，OpenClaw 不知道用哪个 bot 账户推送，默认走 main。

另外，to 只负责“推给谁”（用户 / 群 / 频道），accountId 负责“用哪个 bot 发”。这两个字段职责不同，缺一不可。

有问题的配置：

1
2
3
4
5

"delivery": {
  "mode": "announce",
  "channel": "telegram",
  "to": "YOUR_USER_ID"
}

解决方案

在每个 job 的 delivery 中加上 accountId，同时在 job 顶层加上 agentId。建议把执行超时提到 120 秒（字段 timeoutSeconds）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "id": "xxx",
  "agentId": "news",
  "name": "每日新闻推送",
  "timeoutSeconds": 120,
  "payload": {
    "kind": "agentTurn",
    "message": "执行新闻脚本并发送结果给用户"
  },
  "delivery": {
    "mode": "announce",
    "channel": "telegram",
    "accountId": "news",
    "to": "YOUR_USER_ID"
  }
}

推送目标的两种正确姿势

方案 A（推荐）：同一个用户，按不同 Bot 身份推送

这种方式最适合你当前“4 个 Bot 各司其职”的场景。to 全部写你的用户 ID，accountId 分别写 main/news/growth/kb，消息会显示来自对应 bot。

1
2
3
4
5
6
7
8
9
10

{
  "agentId": "news",
  "timeoutSeconds": 120,
  "delivery": {
    "mode": "announce",
    "channel": "telegram",
    "accountId": "news",
    "to": "YOUR_USER_ID"
  }
}

方案 B：推送到群 / 频道 / 话题

如果要发到频道，不要填 bot 用户名（如 @gamehu_news_bot），而是填频道 chat id（通常是 -100...）。并确保对应 bot 已加入目标群/频道且有发言权限。

1
2
3
4
5
6
7
8
9
10

{
  "agentId": "news",
  "timeoutSeconds": 120,
  "delivery": {
    "mode": "announce",
    "channel": "telegram",
    "accountId": "news",
    "to": "-1001234567890"
  }
}

各任务对应关系

修改完 jobs.json 后重启服务即可生效：

1

cd /opt/openclaw && docker compose restart

进阶玩法：接入 Step-3.5-Flash，并支持会话级切换（第11.6步）

最近我把底层模型又补了一档：Step-3.5-Flash。但这里有个非常容易搞混的点，我一开始也踩了坑：

🚨 坑位 18：想要“随时切模型”，不等于要改全局默认模型

如果你直接把 agents.defaults.model.primary 全局切到 Step，看起来省事，实际上会把别的会话、别的 Bot，甚至定时任务一起带偏。
更稳的做法是：

• 全局默认模型继续保持不变，我这里还是 bailian/kimi-k2.5
• 把 step/step-3.5-flash 注册成一个可选 provider
• 需要的时候，直接在 当前 Telegram 会话 里发送 /model ... 切换

Step provider 配置示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

{
  "models": {
    "mode": "merge",
    "providers": {
      "bailian": {
        "baseUrl": "https://coding.dashscope.aliyuncs.com/v1",
        "apiKey": "YOUR_BAILIAN_API_KEY",
        "api": "openai-completions",
        "models": [
          {
            "id": "kimi-k2.5",
            "name": "kimi-k2.5",
            "contextWindow": 256000,
            "maxTokens": 8192
          }
        ]
      },
      "kimi": {
        "baseUrl": "https://api.moonshot.cn/v1",
        "apiKey": "YOUR_KIMI_API_KEY",
        "api": "openai-completions",
        "models": [
          {
            "id": "moonshot-v1-128k",
            "name": "moonshot-v1-128k",
            "contextWindow": 131072,
            "maxTokens": 8192
          }
        ]
      },
      "step": {
        "baseUrl": "https://api.stepfun.com/v1",
        "apiKey": "YOUR_STEP_API_KEY",
        "api": "openai-completions",
        "models": [
          {
            "id": "step-3.5-flash",
            "name": "Step 3.5 Flash",
            "contextWindow": 256000,
            "maxTokens": 8192
          }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "bailian/kimi-k2.5"
      },
      "contextTokens": 131072
    }
  }
}