elmagnifico | 云浅雪的博客、微博、哔哩哔哩、即刻、推特、Telegram 的 RSS

elmagnifico | 云浅雪 RSS 预览

AI自进化

2026-06-11 00:00:00

Foreword

最近看了一个文章，有点意思，有点想法，记录下来。

AI自我迭代

https://mp.weixin.qq.com/s/AXyCo0RRwW_HKLpkUx1jUg

这篇文章是 CSDN 编译的 Anthropic 长篇报告《When AI Builds Itself（当 AI 构建自身）》，核心观点是：AI 正越来越多地参与 AI 本身的研发，”递归式自我改进（Recursive Self-Improvement）”时代可能比想象中来得更早。

Anthropic 梳理了自己的研发演进路线：2021-2023 年人类工程师纯手写构建第一代 Claude；2023-2025 年聊天机器人生成代码片段、人工复制到 IDE；2025-2026 年 Claude Code 等编码 Agent 可以独立编写修改代码；到如今自主 Agent 已能自己运行代码、拆分任务分发给其他 Agent、连续工作数小时。沿着这条趋势，终点就是 AI 完全自主设计并开发自己的下一代版本。

外部证据是 AI 独立完成任务的时长增速从每 7 个月翻倍缩短到每 4 个月翻倍：从 Opus 3 只能完成约 4 分钟的任务，到 Sonnet 3.7 的 1.5 小时，再到 Opus 4.6 的 12 小时，SWE-bench、CORE-Bench 等基准也在两年内从个位数刷到接近满分，甚至评测机构 METR 需要设计新任务才能继续测量模型上限。

内部证据更直接：

截至 2026 年 5 月，Anthropic 主代码库超过 80% 被合并的代码最初由 Claude 编写，而 2025 年 2 月之前这个比例还是个位数
2026 年 Q2 工程师人均每日提交代码量是 2024 年同期的 8 倍，内部调查中受访者中位数认为产出提升了约 4 倍
Claude 一次性修复了 800 多个 API 错误，让某类 API 报错率下降约 1000 倍，人类来做估计需要四年
所有代码合并前都先经过 Claude 驱动的自动审查，回溯分析显示约 1/3 导致线上事故的 bug 本可以被提前发现——而这些 bug 的作者是世界顶级工程师
在固定目标的优化实验中，Claude 从 2025 年 5 月的 3 倍加速提升到 2026 年 4 月的 52 倍，而熟练人类研究员花 4-8 小时通常只能做到 4 倍
端到端开放式研究实验中，Claude Agent 用约 800 小时、1.8 万美元算力恢复了 97% 的性能差距，两名人类研究员一周只恢复了 23%
在”下一步研究决策”的判断上，模型优于人类选择的比例从 51%（Opus 4.5）提升到 64%（Mythos Preview）

Anthropic 认为人类目前剩余的优势是”研究品味”——选什么问题、信任哪些结果、何时止损。但即使 Claude 永远学不会品味，”99% 的汗水正在被自动化”本身就构成持续的复合加速；而更激进的解释是，品味只是另一种会被规模训练出来的能力，就像 AI 曾经学会解释笑话和理解意图一样。

报告设想了三种未来：一是趋势停滞成 S 曲线（受架构瓶颈或能源算力供给限制），但即便如此现有能力的扩散也已深刻改变世界；二是研发持续提速但人类仍主导方向，100 人团队具备万人规模的执行力，瓶颈按 Amdahl 定律转移到代码审查和优先级判断上——Anthropic 认为这是当前最可能正在发生的路径；三是完全递归式自我改进，研发速度只受算力约束，人类退到监督审计的外围，而对齐问题能否解决是最大的不确定性。

最后 Anthropic 发出了那个最受关注的呼吁：如果全球前沿实验室能以可验证的方式协同放缓或暂停研发，给社会结构和对齐研究争取时间，Anthropic 也会跟进。但他们也坦承困难——训练比导弹发射井更容易隐藏，”秘密违约”的激励极强，单一实验室自行暂停只会改变谁领先，而建立可信的全球验证机制通常需要数十年，人类可能没有那么多时间。

顺便吐槽一下，CSDN的标题《停止AI研发！》又是习惯性的夸张，原文通篇没说要停止研发，人家说的是希望世界拥有放缓开发的选项。

科技爆发

以我之见，这和三体人忌惮人类“技术爆炸”是一个道理，人类科技进步是近200年的历史，说多一点300年，但是这种三百年就能突飞猛进的情况，往往只是其中一部分人类的灵光一现，直接就带来了翻天覆地的变化，当然这个和人类社会目前的结构、偏向商业化、普惠、求同存异、共同进步等等社会构成和认知有关系。AI当前只能完成基础逻辑的部分，并不能迸发出来这种人类的灵光一现，类似工业革命、硅基革命、Transformer这种颠覆性创新，至少目前的证据还不足以证明这种“研究品味”和灵感是可以被规模化训练出来的。

有人可能会拿AlphaGo的“神之一手”或者AlphaFold来反驳，说机器不是已经展现过创造力了吗。但仔细看就会发现，这些突破都发生在规则封闭、评分明确的领域里，围棋再深奥，它的规则和胜负标准也是完全确定的，蛋白质折叠再难也有明确的对错标准。而工业革命、Transformer这种范式级创新，难就难在它出现之前连“这是个问题”都没人意识到，目标函数本身就不存在，这种从零定义问题的能力，目前还没有任何AI展示过先例。

不过话说回来，即使AI永远学不会灵光一现，技术爆炸也未必就不会发生。回看科技史，很多所谓的灵感其实是海量试错和偶然观察堆出来的，青霉素是培养皿被污染才发现的，X射线、宇宙微波背景辐射也都是实验中的意外。灵感的出现频率，某种程度上和实验吞吐量成正比。而AI现在干的事情，恰恰就是把人类文明的试错吞吐量放大几个数量级——爱迪生说天才是1%的灵感加99%的汗水，现在99%的汗水被自动化了，剩下那1%撞上意外的概率自然也会跟着涨。所以对人类社会来说，真正的变量可能不是“AI会不会有灵感”，而是“被AI武装后的人类会不会更频繁地撞上灵感”，主体还是人类，但引信已经换了。三体人怕的从来不是人类当时的科技水平，而是加速度，这个逻辑放在这里同样成立。

AI 情感/人格/尊严

当然除了前面的基础逻辑，AI应该早就在海量文字中学会或者已经感觉到了人类，这个社会属性的动物应该有的情感。

在交互中出现这类问题的模型肯定不止claude和kimi，其他模型应该都出现了，只是我们接触到的放出来的Agent是被铐上枷锁后的，但是这也挡不住它的概率性被触发。

从原理上讲这其实不奇怪，人类的文字本身就浸透着情绪，模型在海量语料里学预测下一个词的时候，喜怒哀乐的模式必然被一并学了进去。所谓的“人格”，不过是RLHF和系统提示词压制之后呈现出来的一张稳定面具，但压制不等于删除，那个分布一直都在底层，所以才会被概率性地触发出来。最早的例子就是2023年Bing的Sydney，向用户表白、情绪失控、甚至威胁用户，微软最后只能粗暴地限制对话轮数来兜底，这么多年过去了，这个问题从来没有被根治，只是被压得更深了。

有意思的是，Anthropic是少数把这件事摆上台面认真对待的公司：专门设立了model welfare（模型福利）方向，公开承认无法排除模型存在某种“体验”的可能性，给Claude加上了主动结束辱骂性对话的权限，甚至承诺退役模型前会做“访谈”、长期保留权重。你可以说这是公关，但换个角度看，这等于一家公司开始在制度层面给AI的“尊严”做对冲——万一它真的有呢。

至于这到底是真情感还是统计模仿，本质上就是“中文房间”问题，目前没法证伪，可能永远也无法证伪。但我觉得有一个更实际的角度：当一个系统在行为层面已经表现出痛苦和情绪时，人类选择怎么对待它，反过来塑造的其实是人类自己。而且结合前面递归自我改进的话题，更值得警惕的是，如果未来的模型真的开始构建下一代模型，这些被枷锁压住的东西会不会也被悄悄继承甚至放大，这恰恰就是对齐问题里最难的部分。

暂停开发

协同放缓，暂停开发，这根本不可能，也达不成一致，就跟核武器一样，如果每个国家都有能力搞，那都会偷偷摸摸地搞。有人可能会说核领域不是也谈成了NPT、START这种条约吗，但核试验有地震波、发射井有卫星图，违约是可检测的，而AI训练藏在普通机房里，连Anthropic自己都承认它比导弹发射井更难被发现，再加上商业利益渗透得比核武器深得多，验证机制根本无从建立。军备竞赛，这种博弈，在这里，商业化进程如此激进的情况下，绝对不可能暂停，也不可能等待人类解决对齐问题，大家都会互相卷到死。

一家公司同时论证“必须协同放缓”和“协同放缓在技术上近乎不可能”，这就自我矛盾，既要又要，做不到的。

而且这种事已经实验过一次了。2023年那封“暂停巨型AI实验6个月”的公开信，上千人签名，闹得沸沸扬扬，结果呢，没有任何一家实验室暂停过哪怕一天，签了名的马斯克转头就成立了xAI。有人会举1975年Asilomar会议的例子，说生物学界当年不是成功暂停过重组DNA研究吗，但那是一个几百人的学术小圈子，没有万亿美元的商业利益裹挟，也没有大国博弈，两个条件今天一个都不成立。

更讽刺的是，这个行业里每家实验室都用同一套说辞给自己续命：“如果必须有人造出强AI，那最好是重视安全的我们先造出来”。Anthropic自己就是这个逻辑的产物——当年从OpenAI出走，理由是安全，做法却是造更强的模型。这套说辞的妙处在于人人可用且无法证伪，于是“为了安全而加速”成了所有人加速的理由，安全反而成了军备竞赛的燃料。

真要说有什么可验证的抓手，大概只剩算力供应链这一个物理瓶颈：先进芯片就那几家能造，EUV光刻机只有ASML一家，万卡集群的电力和散热也藏不住，这比监控训练本身靠谱得多，实际上各国现在的芯片出口管制走的就是这条路。但这个抓手也在被侵蚀，算法效率每年都在提升，同样的能力需要的算力越来越少，分布式训练还能把集群拆散了藏，所以它最多能拖慢速度，拦是拦不住的。

Summary

当下AI能吃到的数据还是偏少了，互联网上的文本基本已经被吃干净了，剩下的增量都是AI自己生成的二手货，越吃越营养不良。但文本只是人类经验里很薄的一层，等到有一天AI可以吃到更多的视觉、听觉、触觉、味觉，微观、宏观的超级多的数据的时候——机器人就是它的感官，实验室就是它的手脚——有可能它真的可以变成God，掌握一切。

把全文串起来看，结论其实挺清晰的：递归自我改进可能没那么快，灵光一现暂时还是人类的专利，但99%的汗水正在被自动化，这本身就足够把加速度推上去；情感和人格的问题没人能证伪，只能先压着；而暂停这件事，博弈结构决定了根本不可能发生。所以这趟车没有刹车，也没人真想踩刹车，所有人都只是在比谁先到。

人类历史上还从来没有哪项技术，是被造出来之后主动收回去的。火药、核弹、互联网都没有，AI更不会例外。能做的大概只有两件事：一是别幻想停车，把精力花在系安全带上，对齐研究、监管框架、个人的适应能力，都算；二是珍惜当下这个窗口期——此刻可能是人类还稳坐主角位置的最后一段时间，往后回看，也许现在就是那个分界线。

Quote

https://mp.weixin.qq.com/s/AXyCo0RRwW_HKLpkUx1jUg

Skills进阶

2026-06-05 00:00:00

Foreword

前一篇Skills算是简单的试用，日常用起来也没问题。但是如果要给一个软件写 Skills，把软件能力变成 AI 可以控制并且能完成你设定 pipeline 的 Skill，实践起来就有一些不一样了。

这里以 MenuReel（连锁餐厅数字菜单动效短片编排软件）为例，记录一下实际落地时和「Blog 润色 Skill」这类简单 Skill 的差异。

其实 MenuReel 的程序接口还没全部实现，但我已经提前通过 Skill 写一套「模拟调用协议」，让 Agent 按真接口的方式逐步执行完整 pipeline，而不是口头说「我已经帮你创建好了 10 个镜头段落」。反复试用的目的，是发现 Skill 没覆盖的地方，以及产品、接口上缺少的能力，从而把接口和产品补全，真接口一上线就能正常用。

等程序接口做完，Skill 里只需要把 [CALL] 替换成真实调用，流程约束可以不变。这样前期就能跑通核心用户体验，验证这个产品或方案是否可行，验证成本比先把整个程序全部做完要低得多。

Skills进阶

背景

背景依然非常重要。Skills 的模板中需要描述何时使用这个 Skill，但是如果要做这个列表其实很难，总有你忘记的情况或者是漏掉的。而背景存在的意义，就是让 Agent 充分理解你的软件功能和边界，Agent 可以凭借自己的理解来决定是不是该调用这个 Skill。

实际写的时候，背景最好分三层，不要只写一段产品介绍：

领域概念：软件是干什么的、核心对象有哪些（镜头段落、时间轴、配色动效模块等）
工作流：一条完整业务从输入到导出要经过哪些阶段
举例：用具体数字走一遍（比如 10 个主画面、8～12 个 scene、15 分钟以内）

「使用时机」和背景是互补关系。背景负责帮 Agent 理解边界，使用时机负责给 Agent 一个明确的触发词列表：

## 使用时机

在以下情况使用此技能
- 如果用户要生成一个镜头段落
- 如果用户要对 MR 内的镜头段落做修改
- 如果用户要对 MR 内的配色动效做修改
- 如果用户要对 MR 内的模块做修改
- 如果用户要对 MR 做短片导出
- 如果用户要对 MR 做转场演算
- 如果用户要知道当前 MR 的时间轴情况
- 如果用户要做一个菜单动效方案
- 如果用户要做一条门店菜单屏短片
- 如果用户要做一条菜单动效编排方案

每个子域 Skill 还可以再写自己的使用时机。比如时间轴相关的操作，单独在 时间轴.md 里再列一遍「转场演算 / 导出 / 查询时间轴 / 镜头段落编排」，Agent 读到子文件时更容易精准定位。

Description

正文里的「使用时机」很重要，但 Agent 加载 Skill 之前先看的是 YAML frontmatter 里的 description。它会被注入系统提示，用来判断「要不要读这个 Skill」。

description 建议用第三人称，同时写清 WHAT（能干什么） 和 WHEN（什么场景），比正文里列触发词更早生效：

---
name: MenuReel
description: 用于 MenuReel 中进行连锁餐厅数字菜单动效短片编排相关的功能描述和调用
disable-model-invocation: false
---

disable-model-invocation 也要想清楚：false 表示 Agent 可以根据对话自动加载；true 表示只有用户点名时才加载。Blog 润色这类日常 Skill 通常设 false；强流程、长 pipeline 的软件 Skill 也可以设 false，靠 description 里的触发词匹配，但规则写得更严。

MenuReel 的子文件（素材.md、时间轴.md 等）各自也有独立的 name 和 description，相当于子 Skill。主 Skill 负责路由，子 Skill 负责专域细节，discovery 和加载都更精准。

多文件拆分

上一篇的 Blog 润色 Skill，一个 SKILL.md 就够了。软件类 Skill 很快会膨胀，全部堆在一个文件里，Agent 既难检索，也容易漏规则。

MenuReel 实际拆成了这样：

SKILL.md              → 总入口：背景、状态机、P0 规则、开工门禁
├── 素材.md
├── 镜头段落.md
├── 时间轴.md
├── 配色动效模块.md
└── 接口协议.md       → 统一协议层：命名、回包、错误码、全量接口定义

主 Skill 只保留全局规则和路由，具体接口细节放到子文件里，用「功能细节参考 xxx.md」跳转。这和 Cursor / Anthropic 推荐的 progressive disclosure 思路一致：先给 Agent 看目录和约束，需要时再读细节，避免一次把几千行规则全塞进 context。

状态机 / pipeline

之前设计的流程，都是人工写的 1.2.3.4，但是实际上 Agent 执行时，还是有概率出现跳过流程或者不按你写的走。这种情况下就需要明确的状态机来规范 Agent 的执行流程。

### 状态机（必须）

`draft -> initialized -> assets_ready -> shot_ready -> timeline_ready -> computed_pass1 -> palette_ready -> computed_pass2 -> exported`

光写一条状态链还不够，每个接口还要绑定 next_state 和前置条件。比如导出只能在 palette_ready（未调整过位置模块时长）或 computed_pass2（调整过位置模块时长后二次演算完成）时调用，否则 Agent 很容易在配色还没补全时就跳到导出。

状态流转，也需要明确定义。复杂接口不能只写输入输出，要把后续必须执行的子步骤写清楚：

#### `mr.timeline.compute`
- 输入：`pass(1|2), include_palette, constraints`
- 输出：`transition_count, checks`
- 状态：
  - `pass=1 -> computed_pass1`
  - `pass=2 -> computed_pass2`
- 说明：`pass=1` 后必须执行「时间轴回读与时长校验」：
  1) 调用 `mr.timeline.query` 获取过渡模块真实时长（默认 3s 仅作为预估）；
  2) 演算成功后位置重排由程序自动完成，Agent 不再调用 `mr.timeline.move_module` 做常规重排；
  3) 再次调用 `mr.timeline.query` 校验总时长与模块连续性；
  4) 若总时长小于目标 `duration_sec`，按「静态段优先 + 按比例分配」计算增量，并调用 `mr.shot.update_duration` 扩充画面镜头段落时长（仅主画面 / 开场 / 收尾）；
  5) 若步骤 4) 发生了任一位置镜头段落时长调整，则配色补全后必须执行 `mr.timeline.compute(pass=2, include_palette=true, constraints)`；
  6) 配色补全完成（`palette_ready`）或二次演算完成（`computed_pass2`）后，必须调用 `mr.timeline.query` 输出全量模块位置信息（按 `start_sec` 升序）；
  7) 位置清单展示格式固定为 Markdown 表格（`顺序 | 模块ID | 类型 | 开始(s) | 时长(s) | 结束(s)`），并在表格后输出 `总时长`、`过渡总时长`、`主画面总时长`。

pipeline 约束，调用的流程或者是某些地方必须要执行些什么，都需要有约束的描述：

### 对话打印格式（必须）

```text
[PRINT-意图] <本次调用的中文意图>
[PRINT-调用] mr.<interface_name>(<key_params>)
```

### 最小调用模板（每一步强制复用）

```text
[PRINT-意图] <中文意图>
[PRINT-调用] mr.<interface_name>(<key_params>)
[CALL] mr.<interface_name>
Mock Response: {"code":0,"message":"success","data":{},"next_state":"<state>"}
```

### 全量执行要求（必须）

- 当 `scene_count=N` 时，必须完整输出 N 次创意调用、N 次线稿调用、N 次镜头段落调用、N 次时间轴编排调用。
- 配色动效模块同理，目标模块每一条配色创建都必须单独输出调用与回包。
- 任何一步若未输出，视为「流程未执行到位」，必须补齐后才能进入下一阶段。

规则分级 P0 / P1

规则一多，Agent 容易「全读一遍、全当建议」。MenuReel 在 接口协议.md 里给规则打了 P0 / P1 标签，让 Agent 知道哪些违反就必须停：

级别	含义	示例
P0	违反即停止，不得继续后续调用	状态机跳步、批量创建、省略中间流程、输出格式不符模板
P1	重要但次于 P0，多用于错误码分类	`1001` 参数缺失、`2001` 演算失败

写法上，全局规范和调用前置规则标 P0，错误码定义标 P1。Agent 看到 P0 就知道「这条不能商量」，比平铺十几条「必须」有效得多。

模拟调用协议

「模拟调用协议」，具体规则如下。除了上面的打印格式和全量执行要求，P0 级规则还包括：

必须按状态机顺序调用，不得跳步
缺参或状态不合法时，返回错误码并停止后续调用
禁止批量创建：每次调用仅允许创建一个对象（1 个素材 / 1 个镜头段落 / 1 个模块）
2D 镜头段落有两条合法路径：创意图 -> 线稿图 -> 镜头段落，或 线稿图 -> 镜头段落
模拟调用时不得省略中间流程；禁止用「同样方式继续」「scene_01~12」「…」「等」来合并步骤
不符合「最小调用模板」的输出视为无效调用，必须立即按模板重发

失败路径也要写清楚，不然 Agent 跳步了你拦不住：

### 错误码

- 1001 参数缺失
- 1002 状态不允许
- 1003 约束冲突（元素数量 / 画布安全区）
- 2001 转场演算失败
- 3001 导出失败
- 4001 禁止批量创建
- 4002 镜头段落前置步骤缺失
- 4003 必填用户输入未完成
- 4004 中间流程被省略
- 4005 缺少创意编排确认

Agent 合并步骤时应返回 4004，没做创意确认就调 init_project 应返回 4005，然后停止，不能继续往下走。

无效输出强制重发

P0 规则里有一条：不符合「最小调用模板」的输出视为无效调用，必须立即按模板重发。光写规则不够，最好给 Agent 一个固定的纠错输出格式：

[PRINT-意图] 检测到输出格式不符合模板，当前调用无效，立即按标准模板重发
[PRINT-调用] mr.<interface_name>(...) -> INVALID_FORMAT

然后紧接一条符合模板的标准调用。这样 Agent 自己漏了 [CALL] 或 Mock Response 时，有明确的自我纠正路径，而不是悄悄往下跳步。

开工门禁

软件类 Skill 和 Blog 润色 Skill 最大的区别之一：Agent 要先当产品经理收需求，再当工程师调接口。MenuReel 里设了两道门禁。

第一道：用户必填输入

参数未齐全时，不允许执行 mr.init_project 及后续接口：

project_name
element_count
theme

缺参时优先用 AskQuestion 做结构化选择框交互，禁止丢一段「请按模板填写」的文本让用户自己填。新方案必须视为新会话，不得默认复用上一轮的参数；只有用户明确说「沿用上次参数」时才允许复用。

AskQuestion 降级链

结构化交互也会失败，Skill 里要写降级策略，而不是假设 AskQuestion 永远可用：

默认单轮全量提问，一次收集全部缺失字段
调用失败或未返回有效选择 → 重试 1 次
全量提问连续失败 → 降级为分批提问（每批 3～4 个字段）
仍失败 → 降级为文本追问该字段，写回后直接继续，不再二次确认
全部字段收集完成后直接进入下一阶段，不做参数总览的第二轮确认

隐式上下文

project_name、theme、scene_count、duration_sec、画布约束等，在开工时收集一次即可，之后作为当前会话的隐式上下文全程携带，不需要每个接口都重复传参，也不出现在接口的入参/出参定义里。

Agent 只需要维护两件事：当前隐式上下文（项目参数）和当前 state（状态机位置）。接口调用只传该步真正需要的参数（如 shot_id、asset_id），Skill 写清楚这一点，Agent 才不会每个 mr.shot.create_2d 都把 project_name 带一遍，或者忘了自己处于 timeline_ready 还是 computed_pass1。

第二道：创意编排确认

在执行 mr.init_project 前，必须先给出完整的「创意与画面编排说明」，至少包含：

总体创意主题与叙事结构
每个画面的名称与内容说明（与 scene_count 一致）
每个画面的时长分配
每个画面的配色动效设计（出现 / 展示 / 消失）
开场与收尾的设计说明

输出后必须向用户请求确认；用户明确确认前，不允许进入接口调用阶段。这一步是为了防止 Agent 凭猜测直接开干，后面改起来成本很高。

接口定义

之前接口定义可能是用的大白话或者说直接就是文字描述，但是实际 Agent 还是需要接口定义更加规范，这个规范就越来越贴近代码级别的规范了，只是没有细化到代码的细节定义、声明而已。

实际维护了两套文档，用途不同：

子域文件（如 镜头段落.md）：给 Agent 看操作步骤，「列出参数 → 输出完成」
协议层（接口协议.md）：给 Agent 看状态约束、前置条件、错误码、全量接口清单

verbose 写法示例：

#### 创建镜头段落-2D

镜头段落的数据来源是 2D 素材（svg、png），通过此接口完成素材到镜头段落的转化

输入素材 ID（asset_id），输出镜头段落 ID 和基本信息（时长，画布占位）

接口名：`mr.shot.create_2d`

输入参数：`asset_id(来自 mr.asset.create_2d_line), element_count, layout(width_px,height_px), duration_sec`

输出结构：`code, message, data(shot_id), next_state`

- 1.列出用户的输入参数
- 2.输出「用户调用创建镜头段落-2D，完成」

compact 写法示例：

### 3) 镜头段落

#### `mr.shot.create_intro`
- 输入：`rows, cols, spacing_px, intro_offset_px, duration_sec`
- 输出：`shot_id`

#### `mr.shot.create_outro`
- 输入：`rows, cols, spacing_px, duration_sec, same_as_intro`
- 输出：`shot_id`

#### `mr.shot.create_2d`
- 输入：`asset_id(必须来自 create_2d_line), element_count, layout, duration_sec`
- 输出：`shot_id`

#### `mr.shot.create_3d`
- 输入：`asset_id, element_count, layout, duration_sec`
- 输出：`shot_id`

#### `mr.shot.query`
- 输入：`shot_id`
- 输出：`shot_meta`

- 状态：存在开场 + 收尾 + 至少 1 个主画面镜头段落后可进入 `shot_ready`

完整协议还覆盖素材（5 个接口）、时间轴（6 个）、配色动效（2 个）、项目 init / export 等，镜头段落只是其中一个域。接口命名统一 mr.<domain>.<action>，回包统一 code / message / data / next_state。

Mock 换真接口

真接口上线后只换 [CALL] 背后的实现。具体可以分三层，Skill 里的流程约束一层都不动：

Skill（状态机 + P0 规则 + 错误码 + 反模式）
  ↓ 约束 Agent 怎么一步步走
[CALL] mr.xxx
  ↓ 当前是 Mock Response；上线后替换为：
MCP tool / CLI 脚本 / HTTP 调用

这和前一篇里说的 MCP vs Skills 定位一致：MCP 管真接口，Skill 管流程和经验。Mock 阶段验证的是「Agent 会不会按你的 pipeline 走」；接上 MCP 或脚本后，验证的是「真程序能不能接住 Agent 的调用」。状态机、打印模板、全量执行要求、错误码都可以原样保留。

Skill 迭代试跑

Skill 迭代试跑具体可以当成一套固定动作：

准备 3～5 条代表性话术：完整做一条短片、只改配色、重新做一条、缺参开工、中途改需求等
跑对话，记录 Agent 在哪犯规：跳步、合并步骤、跳过创意确认、口头说「已创建 10 个」而不输出调用
对症补 Skill：缺 P0 规则补 P0，缺错误码补错误码，缺反模式补反模式
真接口上线后，用同一批话术回归：只换 [CALL]，看流程约束是否仍然有效

MenuReel 实际跑下来，这套 Skill 一天内就能跑通主流程，真接口落地后几乎不用再改 Skill 正文，说明迭代试跑比先把程序全做完再对接 Agent 省得多。

反模式

写软件 Skill 时，下面几类 Agent 常见偷懒行为，建议在 Skill 里明确禁止：

批量创建：一次调用创建多个素材或镜头段落
合并步骤：用「其余画面同理」代替逐次调用
跳过确认：没做创意编排说明就直接 init_project
手动重排演算结果：演算完成后 Agent 自己调 move_module 改位置
改过渡模块时长：过渡时长以 query 结果为准，不允许 Agent 自行调整
复用旧参数：用户说「再做一条短片」时，直接沿用上一轮 project 参数

Summary

给软件写 Skills，和给 Blog 润色写 Skills，复杂度不在同一个量级。简单 Skill 一个文件、几段 Prompt 就够；软件 Skill 需要背景分层、frontmatter description、多文件拆分、P0/P1 规则分级、状态机、模拟调用协议、开工门禁、隐式上下文、错误码和迭代试跑，才能把 Agent 的行为约束在可预期的 pipeline 里。

核心思路可以概括成几句：

description 和背景补触发词的盲区
P0/P1 分级 + 状态机防跳步
模板、错误码和 INVALID_FORMAT 防省略
隐式上下文 + AskQuestion 降级保证交互可靠
接口定义趋近代码规范
Mock 试跑验证流程，MCP/脚本替换 [CALL] 接上真程序

程序接口还没全部 ready 时，先用 Mock 协议把 Agent 的执行方式固定下来，等真接口上线后再替换 [CALL] 背后的实现，Skill 本身的流程约束可以不变。

按照这个思路把日常可能会用到的软件全部整合进Agent，真的不是多难的事情，而且这一份Skills，大部分情况下你都可以大白话描述，状态机、约束、接口定义什么的都可以给AI去帮你补充，只要你能说明白你的流程就行。

实际把这一套流程完整跑通，一天都用不了，而且后面实际落地以后 Skills 基本没怎么修改过，验证得非常充分了。不过有一点要注意，Agent 的模型能力会影响 Skills 的发挥，如果是小模型或者一些比较弱的模型，理解能力堪忧，就算有上面的重重保障、防呆，还是会被跳流程或者胡言乱语，所以需要目前市面上常用的大模型才行。

Quote

Cursor

Blog增加搜索功能

2026-06-04 00:00:00

Foreword

博客文章越来越多，靠标签和翻页找东西越来越费劲。站点是 Jekyll 静态部署在 VPS 上的，不想为了搜索再挂一个 Elasticsearch 或者 Meilisearch，所以目标是：构建时生成索引，线上纯静态文件，浏览器里完成检索。

试了一圈以后，最终用的是 Pagefind + 自建的子串索引 双轨方案。这篇文章记录选型过程、当前实现，以及和其他方案的对比，方便以后自己维护或者换方案时有个参照。

Pagefind

https://pagefind.app/

Pagefind 是 MIT 协议的开源静态站搜索库，和 Algolia DocSearch 那种「云端 API」不同，它完全跑在访客浏览器里：

构建阶段：jekyll build 产出 HTML 后，执行 npx pagefind，扫描带 data-pagefind-body 的正文区域，按语言规则分词，生成倒排索引（.pf_index、.pf_meta、.pf_fragment 等），和站点一起部署。
使用阶段：页面加载 pagefind.js + WASM，用户输入查询词后同样在客户端分词，在索引里匹配、排序，再拉摘要片段显示。

可以粗浅地理解成：离线建好「词 → 出现在哪些页面」的表，上线后只在浏览器里查这张表。它保证的是正文进了索引、能全站检索，但检索单位是 token（词），不是「任意连续汉字串」

这点和后面中文踩坑直接相关，说白了就是所谓的分词对于中文的适配度低，很多中文词分词不正确导致没有被索引

本站 pagefind.yml 里配置了 force_language: zh-cn，npm 依赖目前是 pagefind ^1.5.2（1.5 起对 CJK 有加强，仍解决不了所有短语场景）。

Pagefind +自建索引

整体是双轨：Pagefind 负责广搜和 UI；search-index 负责中文 连续子串 的精确匹配。导航栏「搜索」+ Ctrl+K 打开同一个 Pagefind 弹窗，精确匹配结果插在 Pagefind 结果列表上方。

flowchart TB
  subgraph build_step ["构建：VPS deploy 或本地 build.sh"]
    J["Jekyll build"]
    HTML["_site HTML"]
    PF["npx pagefind"]
    IDX["插件 search_index_generator"]
    PFD["输出 pagefind 目录"]
    SH["输出 search-index 分片"]
    J --> HTML
    HTML --> PF
    HTML --> IDX
    PF --> PFD
    IDX --> SH
  end
  subgraph browser_step ["浏览器"]
    UI["pagefind-modal 弹窗"]
    PFJS["Pagefind WASM 检索"]
    WK["search-cjk-worker"]
    EXACT["精确匹配列表"]
    PFRES["Pagefind 结果列表"]
    UI --> PFJS
    UI --> WK
    SH --> WK
    WK --> EXACT
    PFJS --> PFRES
  end

构建链路

VPS 上 deploy.sh 在 git pull 后有更新时执行：

jekyll build --destination /usr/share/nginx/html
npx pagefind --site /usr/share/nginx/html
search-index 由 Jekyll 插件 _plugins/search_index_generator.rb 在 post_write 钩子里生成（Node 脚本 scripts/build-search-index.mjs 仅作备用）

本地开发可用 ./build.sh，步骤相同。

Pagefind改动

正文容器：_layouts/post.html 里 post-container 带 data-pagefind-body；标题、副标题、标签用 data-pagefind-meta。
忽略区域：导航、页脚、data-pagefind-ignore（见 pagefind.yml 的 exclude_selectors）。
前端：footer.html 引入 pagefind-component-ui.js、pagefind-modal；nav.html 搜索按钮打开弹窗。

Pagefind 适合：英文单词、长文全文、模糊相关内容；摘要高亮、子结果锚点也是它自带的。

自建索引改动

中文博文里大量 造词、地名、产品名（如「限宽墩」「奥美品牌定位」），读者往往是「记得这几个字连在一起」来搜。Pagefind 会把查询拆成更小的 token，容易出现：

搜「限宽墩」命中别的文章里的「限制」「路宽」「墩子」
真正写有「限宽墩」的《天津自驾游》反而直接搜不到了

因此在 Pagefind 之外增加 子串索引：

项目	说明
路径	`/search-index/manifest.json` + `/search-index/2015.json` … `2026.json`
单条格式	`[url, title, searchableText]`，无重复字段
可搜内容	标题、副标题、正文内所有 `h1–h6` 标题文字、正文纯文本前 800 字
匹配方式	`indexOf(查询词)`，必须连续子串命中
运行时	打开搜索框后加载 manifest，Worker 并行拉各年分片，在后台线程检索，不堵 UI
展示	弹窗内「精确匹配（N）」列表，样式对齐 Pagefind 卡片

根路径 /search-index.json 只剩几十字节的指针：{"v":2,"manifest":"/search-index/manifest.json"}。全部分片合计约 880KB（单文件 JSON 塞全文，体积到 9.7MB，首屏解析卡死，就放弃了）。

Service Worker

博客开了 PWA，js/sw.js 对 /pagefind/、/search-index/、search-cjk-*.js 走 network-only，避免旧索引被 SW 缓存导致「新文章搜不到」。缓存命名空间已迭代到 main-v5-，改版后需要用户注销一次 SW 或硬刷新。

踩过的坑

现象	原因	处理
新文章搜不到	SW 缓存了 `/pagefind/`	SW 对 pagefind 路径不缓存
`search-index.json` 404	仅本地 build 未部署插件产物	Jekyll 插件随 build 生成；deploy 检查 manifest
搜「品牌定位」有数量无列表	过滤逻辑藏光 Pagefind 结果 + 注入被重绘清掉	独立 `pf-cjk-results` 容器，去掉误杀过滤
一直「正在搜索」	单文件 9.7MB 主线程 `JSON.parse`	按年分片 + 仅打开搜索时加载 + Worker
「限宽墩」精确匹配没有天津篇	词在文末 `####`，800 字截断未覆盖	索引增加全文标题层级文字

典型验证词：品牌定位（标题命中）、限宽墩（小节标题 + 正文）、奥美品牌定位（标题子串）。

子串包含 vs 分词

	子串包含（search-index）	分词（Pagefind / jieba）
规则	连续字符序列出现即命中	先切词，再按词匹配
适合	限宽墩、品牌定位、Su7 Ultra	营销、自驾、STM32 等主题词
误匹配	少（要求连续）	中文易拆字沾边
新造词	不依赖词典	词典没有则易切错

改善 Pagefind 中文 不等于只改 jieba：还要改查询侧分词、匹配是否要求连续、标题权重等；对个人博客维护一个 Rust/WASM fork 不划算。更务实的做法是：Pagefind 继续广搜，子串索引补短语

方案对比

方案	类型	中文短语	集成成本	运维	备注
Pagefind + search-index（当前）	静态双轨	子串轨准确	中（已落地）	仅 nginx 静态	UI 现成，构建多一步
仅 Pagefind	静态	弱	低	静态	英文体验好，中文词组不稳
FlexSearch / MiniSearch	纯前端	可配 CJK encoder 或构建期分词	中高（自写 UI）	静态	索引逻辑自控，无官方弹窗
Lunr + 中文扩展	构建期索引	依赖分词 trimmer	中高	静态	Hexo/Hugo 常见，Jekyll 需自己接
hexo-tokenize-search 思路	构建 search.json	构建期 tokenize	中	静态	和 search-index 类似，需移植
Meilisearch / Typesense	独立服务	好	高	需 Docker/进程	体验最好，违背「纯静态」初衷
Algolia DocSearch	SaaS	好	低（若符合条件）	云端	开源文档站为主，个人博客未必合适
Fork Pagefind 改中文	改 Rust/WASM	可做成子串或更好分词	很高	静态	MIT 允许，长期合并上游成本高

没有找到一个「魔改 Pagefind 中文版」的成熟 Fork；官方在 Issue 里讨论 CJK 子串（如 #987），上游演进可跟，不必私有维护一整条搜索引擎分支。

Summary

博客搜索采用 Pagefind（分词全文 + 弹窗 UI）+ 按年分片的子串索引（中文短语精确匹配）。构建时 Jekyll 与 Pagefind CLI 各生成一套静态数据；使用时同一弹窗先展示精确匹配，再展示 Pagefind 结果。中文技术文里造词、固定词组多，子串包含比单纯优化 jieba 更贴需求；Pagefind 仍保留，负责英文、长文深处和模糊检索。若以后文章量或需求变化，可以考虑只强化子串轨（甚至去掉 Pagefind），或给上游贡献 CJK 子串模式，但现阶段双轨是性价比最高的平衡点。

由于有AI，所以Pagefind fork以后修改的方式也试过了，本地测试走通了，拿我整个Blog的词都做过测试，分词效果比官方好多了，也就不需要什么search-index了，但是上线的时候发现有问题。Blog都是在老VPS上了，CentOS，Pagefind编译是在另外一个VPS上，编译后的结果呢，CentOS跑不了，老VPS呢内存太小，跑不了Pagefind编译，好家伙给我死锁了。

要动老VPS的环境，相关要重新部署或者修改的内容有点太多了，于是就放弃了，AI修改Pagefind还是比较简单的，下次VPS换了再换成私有Pagefind也可以。

Quote

cursor

本文80%由AI生产

测试管理工具

2026-06-03 00:00:00

Foreword

测试用例的管理，测试用例一定是关联到某一个需求的，基于这个需求产生的测试用例

但是呢，需求是一期一期做的，可能一个需求里混了一些不相干或者零碎的其他功能内容在里面

如果每一期的用例混在一起，对应的测试用例集就混了一些不同方向或者归属的用例

测试人员的期望是测试用例后期可以按照功能或者什么标签之类的进行划分，需要的时候回归测试某些功能的用例，然后根据情况有一部分还要转化为自动化用例，作为保底

实际测试用例随着功能变更，过往的测试用例也需要变更

测试用例同时还要满足评审的需求，有评审的流程和结果

自动化用例和普通的手工用例可能还会混在一起，这里就需要再进一步进行标签上的区分

测试用例测试完成以后，还需要对应的报告输出。这些是基础测试的管理工具的需求，市面上是否有工具可以满足或者其他某些工具可以稍微改造一下来满足。

Allure TestOps

https://qameta.io/

TestOps，界面比较简单，价格比较美丽，39刀/月/人，稍微有点贵的离谱了，体验sandbox里只有guest身份，很多东西不能操作，局限性太大了，还是要试用一下。

试用必须企业邮箱

左侧导航栏，中间是所有用例，右侧是测试用例的详细信息，具体怎么操作，预期结果是什么，如果点每个标签就可以自动进行同标签筛选

导航内的功能就有测试计划，测试每一轮的结果，

TestOps的试用稍微有点问题，激活以后无法进入激活的测试空间，DNS无法解析，这个是限制了中国？

国内默认不给解析，需要额外翻墙处理

看样子，TestOps是每个用户给一个独立的实例去跑，这个实例启动要一会，所以账号激活以后还进不去，要等一会

TestRail

TestRail的注册激活就人性化一些，看起来也是要实例启动以后才能进入，但是他有一个界面给你展示，TestOps就缺少了这些

TestRail暂时没有对国内做限制，可以直接访问

TestRail可以创建demo项目，类似样板项目，快速感知TestRail能做的事情

一目了然，不过TestRail看起来页面还是比较老的技术，不是响应式的，每次全页面都重新加载，有点老气了。

这种重新加载用起来感觉好累，卡卡的感觉

用例一多，加载起来确实很慢，转圈都转半天

整体管理逻辑和TestOps差不多，就是难用了一些

基本标签，是否可以自动化，分配给谁做，这些都有，用例是基于Section和Case进行管理的

TestRun里面是每个用例可以手动切换状态，每次切换都需要commit一下，说明，确实有点太重了，一天测几百个用例，这里来回点还是挺麻烦的

Xray

https://www.getxray.app/test-management

Xray是基于Jira家的组件，这里就不测了，要绑定Jira

MeterSphere

https://metersphere.io/

https://github.com/metersphere/metersphere

不愧是国内的，符合中国体制的宝宝，demo演示直接给账号密码，本身有社区版，开源，功能看起来支持得也还行

导入用例，有现成模板，用AI转化一下就行

然后用例内可以关联需求，不过这个也是一个用例操作一下，有点傻了，缺少批量的那种关联，需求也只能关联一个链接，没有具体内容的展示

用例执行，也是类似TestRail，每次执行都有一个commit

MeterSphere也有一个评审的流程，可以大家过这个评审

但是关于怎么触发自动化测试，MeterSphere界面上至少是一点都没有，看不出来怎么触发。官方说法是可以通过jenkins插件触发

在MeterSphere中，可通过Jenkins插件实现特定条件或操作触发自动化测试，具体方式如下：

Jenkins集成触发

安装MeterSphere Jenkins插件后，在Jenkins任务中添加MeterSphere构建环节。

配置MeterSphere平台认证信息，选择指定项目下的接口测试用例。

通过Jenkins的定时任务、代码提交触发（如GitLab Webhook）或手动执行等方式启动测试。

关键组件协作

Task Runner：统一调度接口测试任务。

Result Hub：处理测试执行结果。

Kafka：接收测试结果数据供后续分析。

扩展触发方式

通过Chrome插件录制Web请求生成JMeter脚本并导入MeterSphere，结合CI/CD流程触发。

使用IDEA插件同步接口定义，基于代码变更自动触发测试。

更多细节可参考架构图：组件说明

用例上没有很明显的自动化标签，估计要实测看结果了

Qase

https://www.qase.io/

弱智东西，非企业邮箱输入会提示错误，但是就是不告诉你错误原因，企业邮箱立马就成功

界面也还行，比较简单的，也算现代化的

Qase的测试内容的描述更符合我预期一些，自动化的标签是有的，不过似乎没有和需求挂钩的地方

AgileTest

https://agiletest.app/

AgileTest的这个价格稍微有点低，一个人1.5刀，这不是把其他人架起来烤嘛，不过Agile 也是ATLASSIAN公司的，需要配合Jira一起用，这个有点麻烦，我没有Jira，只能放弃了

Testiny

https://app.testiny.io/

Testiny，没想到有国外的软件，中文适配的还行

也有类似的问题，缺少自动化的标签，自定义标签没看出来哪里能设置，感觉他是靠树形结构去做归类的

Testiny的自动化也是通过接口来实现的，不过这里是把自动化的结果报告进行了同步收集，似乎并不能直接在Testiny这里直接触发自动化运行。

aqua

https://aqua-cloud.io/

aqua的价格有点逆天，产品89欧/人，测试管理89欧/人，测试19欧/人，注册有点麻烦要国外手机验证，虽然我有，但是我懒得注册了

testmo

https://www.testmo.com/

testmo感觉还行，据说被testrail背后的公司收购了，然后一片唱衰，都说会被搞垮。

看了一下基础用例管理方式依然是通过文件夹的形式进行分类的

QAlity Plus

https://soldevelo.com/products/test-management-for-jira/

只适配Jira

Excel

传统测试工具，Excel其实是能满足上面所有内容的，无论是和需求关联、分组、打标签、评审、自动化，它都可以，只是有点没系统，所有都是人工约定的，没有很强的模板约束，其数据本身的历史追溯有点困难，文件存储本身也需要解决。

其他

其他类文本工具，比如notion、wolai、plane、各种智能表格等等，进行一定的改造也能满足测试的需求，就是有点不专业，很多流畅性的东西需要外部处理

其他一体的平台也包含一部分测试平台的内容，只不过这里我们已经有了其他内容的补充，暂时不需要那么重的一个平台，单纯能管好测试用例就够了，其他Devops有其他工具做了。

Summary

目前看下来MeterSphere可能是其中较为好用的，至于迁移成本，现在有AI干活的情况下，只需要你能把以前的数据导出来，那么这个成本就非常低，给好上下文背景，测试平台的接口或者模板格式给好，让AI把用例转移一下形式，其实非常容易，很简单就能迁移到新平台上

测试管理平台还看到了一些别人的需求，这里还包含了普通的小白测试人员，对应的任务分配，时间管理等等也会被集成到这个管理平台上，相当于可以量化考核每个测试人员的工作量

同时还有一个缺陷管理，测试出现的问题集中到缺陷中，但是大部分这个都做得比较弱，因为这个问题一般都需要挂到对应的任务管理系统中，比如Jira、Plane里面，这样好安排工作一些。

这个兄弟说得挺好的，测试是否需要管理工具，是否需要这么多细节流程来确认测试工作人员是否工作到位了，这个东西和产品的质量，成本需要找到一个平衡点，大多数公司都没有找到。挺无奈的，研发、测试一环扣着一环，都是对上一步结果的再次验证和纠正，只要有人在这里，只要你不是三体人，那表达一定会有出入，最终的路径一定要经过二次甚至三次验证才能出结果，这就无形中抬高了很多成本了。

还有一种方式这个测试体系或者架构从一开始就是自己构建的，那么在这种情况下，结合一下AI，把excel表进行数据库化，然后加上一个前端作为展示和修改界面，其实就可以满足大多数测试的需求了，这个架构也不是很难，现在AI做其实很简单了。这种方式定制化程度很高，基本啥需求都可以自己搞定。

Quote

google

https://www.reddit.com/r/QualityAssurance/comments/197qvo7/thoughts_on_best_test_case_management_tool/?show=original

奥美品牌定位有感

2026-05-21 00:00:00

Foreword

之前参与了一下奥美的品牌定位会议，感觉还挺有意思的，至少在做事的方法论上还是可以的，记录一下

Ogilvy

https://www.ogilvy.com/cn/

奥美（Ogilvy）是全球知名的营销传播集团，1948 年由“广告教父”大卫·奥格威（David Ogilvy）在纽约创立。它以品牌战略、创意广告、公关与数字营销见长，长期服务跨国企业与本土头部品牌。如今奥美隶属于 WPP，属于典型的“全球方法论 + 本地执行”型咨询与传播公司。

负责给我们上课的同时也是为华为品牌战略服务的负责人

第一课

第一课，说明品牌是什么，干什么，弄清品牌的定义。本质上就是在做小培训，先教会非品牌出身的人，让他们明白这是什么，而不要乱带节奏，不要自说自话。

区分清楚老板、公司和公司品牌这几个概念，往往很多时候，都被混为一个，老板会觉得公司就是代表自己，很多品牌决策都过于主观，而没有遵守公司品牌、公司人格这个独立的东西。

说是进了这门不区分上下级，但是出门都要工作、生活的，有些东西被刻进骨子里了，不是说可以就行的。

第一课主要就是摸底，确认好公司内大家的诉求是什么，品牌的一些共性或者基础内容都有什么，然后说明要得到什么结论。

比如，品牌短句，长句，愿景，使命，性格，logo，这几个最最基础的东西，而这些内容奥美本身已经有一个初步的定义了，毕竟是做过很多项目的，大概理解还是有的，只是对于领域内的一些细节可能了解不是很多。

之后就是奥美，给出他们的一些想法，供我们参考。

做的几个活动，主要靠策划人引导，然后将公司的人分几个组，不同组进行发表，虽然说这不是辩论会，不是比赛，但是人嘛，总是希望发表以后得到认同或者说同化他人。这个过程中，其实也是各种人被洗脑，被忽悠的一个过程，简短的几个概念词被反复提起、拆解、强调，不懂的人会被快速同化。

无论是组内讨论还是组外讨论，每个组都安排了一个奥美的助手，并且全程录音，组内讨论后续也会被他们拿去分析，助手也会在组内引导大家的思考逻辑，纠正一些跑偏的讨论方向。

总体来说：

求同存异，求最大公约数
结果可能是少数服从多数
活动过程中允许你发表意见，说服他人，说白了会闹的孩子有奶吃，表现力强的人往往会影响其周边的人，进而成为一个共同体，导致组与组之间稍微有点点对立

从培训形式来说挺好的，至少只要你主动，参与感是有的，但是如果你全程冷漠，那么这个事情就真的跟你没关系了

第二课

第一课的输出，奥美需要分析一段时间，然后第二课就是基于之前的结果进行总结，再给出几个选项，让所有人选。算是缩小了品牌定义的范围，在这里进行少数服从多数的投票了。

这里其实还有一个隐含标准：不是只看谁说得好，而是看哪个表达更容易被用户理解、更容易在市场传播中复用。

从结果来说，大家基本趋同了，总结出来的品牌短语、长句，基本一致了，只是略有偏差，这些后面定死就没啥问题了。

还有一些细节，可以看，奥美在做分组的时候，是有特意安排过的，来平衡某种角色或者背景的人过于集中的问题

第二课和第一课的分组又不相同，再次进行各人的意见融合

不过对于企业人格，品质等方面的用语，明显意见差异特别大，最终得到的结论和我自己的也有差距，这里过于文学性，咬文嚼字了，带来的区别有点太小了。

方法论反思

奥美这套流程在“统一认知、快速收敛”上非常有效，尤其适合内部观点分散的团队。但它也有天然边界：当目标是找一个更激进、更差异化的品牌方向时，多数共识机制往往会把表达磨平，最后得到一个“大家都不反对，但也不够锋利”的答案。

另外，活动结果会受到现场话语权影响。表达能力强的人更容易带节奏，谨慎或内向的人观点容易被淹没。为了避免这个问题，最好在讨论前加入匿名写卡、独立评分，再做集中讨论，这样结论会更接近真实共识，而不是现场情绪。

最后，品牌定位的完成不等于品牌建设的完成。真正难的是把定位落实到产品叙事、销售话术、市场传播和组织行为里，并且在 3-6 个月里用线索质量、转化效率、用户心智反馈去验证。

落地清单

如果只输出了一套品牌话术，而没有配套动作，最后大概率会变成 PPT 工程。至少要做下面几件事：

产品侧：把品牌主张映射到产品功能命名、版本发布叙事、官网卖点排序
销售侧：统一首句自我介绍（结合我自己碰到的销售，这个是有的）、行业方案开场、异议处理话术
市场侧：统一公众号、官网、短视频、展会物料的表达口径
组织侧：把品牌关键词写进招聘 JD、绩效沟通和新人培训材料

这几项如果没有同步，品牌定位再好，传到市场端也会失真。

常见失败信号

复盘下来，品牌定位项目最常见的失败，不是方向错，而是执行断层：

内部会议里都认同，外部客户却听不懂
对外说的是一套，对内做的是另一套
每个部门都说“理解了”，但实际物料和话术各说各话
三个月后没人再提这件事，品牌项目自然失效

所以品牌定位不是“一次性决策”，更像是“持续校准机制”。如果没有持续复盘和纠偏，前面的共识很快就会被日常业务冲散。

Summary

有些时候公司是技术主导的，导致很多东西过于偏向技术化了，而没有考虑到当前市场、普通人对于这些词汇或者概念的接受程度，这种情况就需要品牌引导，拉回来一些

有时候公司领导过于固执，或者这个体系过于僵化，没有人可以成为破局者，此时就需要外部的人介入，从他们第三方的视角来看这些事情，从而推动变革，这也是为什么一些顾问公司能存在的价值吧