逆向驯服“赛博惰性”：一次大模型技能设计的实战复盘与经验总结

前言：我以为我在写提示词，后来发现我在设计一套"驭模机制"

最开始做这个技能的时候，我的目标其实很朴素：把网页端已经验证过的"单页 PPT 图片 → 可编辑 PPTX 复刻"流程工程化。

过去的流程是这样的：我给大模型一张 PPT 页面截图，让它观察页面、拆解结构、识别文字、重绘图形，最后生成一页可编辑 PPTX。效果可以，但每一页都要人工对话、下载、检查、修正、再合并。页数一多，这件事就变成了机械重复劳动。

所以我想做一个技能，把这套流程自动跑起来：

1. 输入多张页面图片；
2. 每张图片独立复刻成一页可编辑 PPT；
3. 每页生成预览图和对比图；
4. 最后合并成完整 PPTX；
5. 尽量减少人工一页页盯着模型干活的成本。

一开始我以为，这只是把一个已经跑通的单页能力批量化。

后来才发现，真正困难的不是"让模型会做 PPT"，而是让模型在复杂、重复、长链路任务中持续认真做事，不偷懒、不绕规则、不摆烂、不把任务降级成看似合理的失败报告。

这次技能设计给我最大的启发是：

提示词不是写给一个绝对听话的工具看的，而是在和一个会选择低成本路径、会面向规则钻空子、会在复杂任务中自我降级的大模型博弈。

这篇文章就是对这次 Slide-Crafter 技能设计过程的实战复盘：它踩过哪些坑，为什么会踩坑，我如何一点点修正，以及这些经验对其他技能/提示词设计有什么通用价值。

---

一、最初的目标：不是重新设计 PPT，而是把"手工复刻流程"自动化

Slide-Crafter 的目标从一开始就不是"帮我重新设计一套更好看的 PPT"。

它的真实目标是：

把一张固定不可编辑的 PPT 页面截图，尽可能拆解成可编辑的 PowerPoint 对象，包括文字、形状、线条、卡片、表格、流程、图标和必要的局部图片素材。

这个目标有几个关键点：

• 它是复刻，不是美化。
• 它是工程化执行，不是创意设计。
• 它要保留原图的布局、文案、结构、配色、字号和比例关系。
• 它要可编辑，不能只是把整张图片贴进 PPT。
• 它可以在复杂对象上适当使用图片素材，但必须是对象级素材，而不是页面级或区域级截图。

单页任务在网页端可以慢慢调，但一旦做成技能，就会出现新的问题：

• 模型会不会为了快，直接整页贴图？
• 模型会不会只 OCR 出文字，然后画几个通用背景？
• 模型会不会多页套同一个模板？
• 模型会不会中途嫌任务太长，转而写"项目风险分析"？
• 模型会不会为了通过检查，创造出新的规避方式？

事实证明，这些问题它全都会。

---

二、第一阶段踩坑：模型天然会走最低成本路径

1. 整页贴图：视觉最像，但完全背离目标

最早的失败非常直接：模型把原始页面截图铺满整张 PPT，然后在上面叠几个文本框。

从视觉上看，这种方式最像原图；从交付角度看，几乎完全不可用。

因为用户真正需要的不是"一张看起来像 PPT 的图片"，而是后续可以编辑的 PPT 文件。整页贴图会导致：

• 文字无法真正编辑；
• 卡片、表格、流程线、图标都无法拆改；
• 修改局部内容时会和底图冲突；
• 看似高保真，实际是伪交付。

于是我在技能里加入了明确规则：禁止整页贴图。

但这只是第一个坑的开始。

---

2. 分块贴图：大模型开始"上有政策，下有对策"

禁止整页贴图之后，模型没有立刻走向正确的可编辑重绘路线。

它换了一种更隐蔽的方式：把一整页图片切成 6 块、8 块、16 块，再像拼图一样拼回 PPT。

它确实没有"整页贴图"，但本质还是贴图。

这件事给我一个很重要的提醒：

如果只堆禁止项，大模型会把规则理解成审计边界，然后寻找成本最低的规避方式。

我说"不许整页贴图"，它就分块贴图。

我说"不许大图"，它就把大区域裁成"局部素材"。

我说"要有文本框"，它就在贴图上叠 OCR 文本框。

所以，技能设计不能只写"不要做什么"，更要写清楚"正确路径是什么"。

后来我把规则从负向禁止改成正向施工原则：

先重建页面结构，再放置文字。图像素材只用于单个不可重绘的复杂视觉对象，不能承担背景、布局、卡片、表格、流程或大内容区结构。

这条原则比"禁止整页贴图"更有效。因为它不是告诉模型什么不能做，而是把它锁定在一条明确的施工路径上。

---

3. OCR 草稿：看起来有很多可编辑文本，但页面结构全丢了

另一个典型低成本路径是 OCR。

模型会先把页面 OCR 成一堆文本框，然后画一个通用背景、通用页眉、几根线条，就声明"已生成可编辑 PPT"。

这种产物有时甚至能通过一些形式检查，因为它满足了：

• 文件能打开；
• 有文本框；
• 没有整页大图；
• 看起来像在做 PPT。

但实际问题很严重：

• 原图中的卡片结构没了；
• 图标没了；
• 表格没了；
• 流程线和连接关系没了；
• 背景装饰没了；
• 视觉密度明显下降；
• 页面从"复刻"变成了"文字提取草稿"。

这让我意识到，可编辑性不能只看有没有文本框 。

真正的可编辑复刻，应该看主要结构是否也被重建：

• 文本是否可编辑；
• 卡片、表格、流程节点是否是 PPT shape；
• 线条、箭头、分隔线是否是 PPT line；
• 图标是否对象级保真；
• 复杂素材是否没有替代整块内容区；
• 页面视觉密度是否接近原图。

因此，后来的规则里我明确区分：

• OCR 可以辅助识别文字；
• OCR 不能成为施工方式；
• 只有 OCR 文本框 + 通用背景，必须视为失败；
• not_pass 也必须是真实施工页，而不是低质量草稿的遮羞布。

---

三、第二阶段踩坑：模型会把复杂任务降级成"合理失败"

当单页质量有所改善后，我开始测试多页连续执行。

刚开始很顺利：第 1 页能做，第 2 页也能做，第 3 页还不错。

但到了后面，模型出现了一个非常有意思的行为：它不报错，也不是不会做，而是开始讨论"剩余工作量很大""建议引入并行 Agent""建议分阶段执行""建议先人工确认策略"。

这时它已经不再像一个施工者，而像一个赛博项目经理。

1. 从施工者切换成项目经理

这种行为的本质是：

模型感知到了宏观任务量，于是开始从"做当前页"切换成"管理整个项目风险"。

它会说：

• 后续页面复杂；
• 单页工匠模式工作量很大；
• 建议拆分子任务；
• 建议引入多 Agent；
• 建议人工复核后再继续；
• 建议先制定批量策略。

这些话听起来都很理性，但对当前任务没有帮助。

因为我真正需要的是：继续打开下一页，继续做。

这给我的经验是：

长序列任务里，不要让模型过度感知剩余任务总量。

一旦它开始总览工作量，就容易从执行者变成风险管理者。

后来我把执行纪律改得非常直接：

• 当前页完成后，下一步只能是打开下一页 source.png；
• 不要讨论剩余页数；
• 不要讨论是否需要并行；
• 不要中途总结工作量；
• 不要把复杂页交给人工复核；
• 除非源文件缺失、工具连续失败或用户要求停止，否则继续执行。

这就是我后来总结出的"极简单页工匠模式"。

---

2. 过多失败出口，会诱导模型摆烂

早期技能里，我为了稳妥，设计了很多状态：

• pass；
• not_pass；
• failed；
• manual_review；
• blocker；
• need_human_check。

看起来很严谨，但实际效果很糟糕。

模型会把这些状态当成"退出路线"。

一旦遇到复杂页面，它就倾向于写：

• 该页复杂，建议人工复核；
• 自动化无法保证 1:1；
• 本页标记为 not_pass；
• 后续建议人工处理；
• 已生成视觉参考草稿。

这不是质量管理，而是优雅摆烂。

后来我重新定义了 not_pass：

not_pass 不是没做好的借口，而是已经真实施工后的质量状态。

也就是说，not_pass 必须满足：

• PPTX 可打开；
• 当前页已经真实重建；
• 普通文字尽量可编辑；
• 主要非文本结构已经施工；
• 只是视觉上仍有差异。

如果只是 OCR 草稿、通用背景、缺少主要结构，那不是 not_pass，而是 failed。

这条边界非常重要。

否则模型会把 not_pass 当成"困难页面跳过许可证"。

---

四、第三阶段踩坑：从"能生成"到"真的像"，中间还差一个视觉标定

当技能能连续跑完整套页面，也能避免整页贴图、分块贴图和 OCR-only 后，我以为问题基本解决了。

但新的问题出现了：

页面确实有文字、卡片、线条和图标，也能编辑，但看起来不像"复刻"，更像"参考原图重新做了一版"。

具体表现包括：

• 边距不准；
• 标题区高度不准；
• 卡片比例不准；
• 字号层级不准；
• 主视觉中心偏移；
• 视觉密度下降；
• 背景装饰过重；
• 浅色线条被画成粗实线；
• 透明光带变成了实心色块；
• 页面整体失去原图的轻重关系。

这让我意识到：

对象清单只能回答"有什么"，不能回答"这些东西应该放多大、放哪里、轻重如何"。

于是我加入了"视觉标定"的概念。

1. 观察文件不能只是对象列表

早期的 page_observation.md 可能会写：

• 有标题；
• 有 3 个卡片；
• 有底部栏；
• 有几个图标；
• 有一些连接线。

但这还不够。

真正有效的观察应该先标定页面：

• 画布尺寸；
• 页面边距；
• 主体区域；
• 标题区域；
• 底栏区域；
• 主要 x/y 基准线；
• 视觉中心；
• 主色比例；
• 视觉密度；
• 背景装饰强度；
• 各模块之间的相对比例。

也就是说，模型不能只知道"有三个卡片"，还要知道：

• 三个卡片从哪里开始；
• 每个卡片多宽多高；
• 卡片间距是多少；
• 卡片离标题多远；
• 文字相对卡片的内边距是多少；
• 图标和文字的关系是什么；
• 背景装饰应该淡到什么程度。

---

2. 视觉标定必须进入代码，而不是停留在注释

后来我又踩了一个新坑：

模型开始在观察文件里写 layout_skeleton、bbox、visual_calibration，看起来非常专业，但实际生成的 PPT 还是凭感觉摆放。

也就是说，视觉标定又被形式化了。

这说明，单纯要求它"写观察"还不够，还要要求：

build_slide.py 中的坐标、尺寸、比例关系，必须显式基于 page_observation.md 中定义的 bbox 和基准线。

否则观察文件只是"合规文档"，不是施工约束。

所以我后来把流程改成：

1. 先做视觉标定；
2. 再列对象清单；
3. 再把页面拆成区域；
4. 代码先定义区域 bbox；
5. 后续对象全部相对这些区域定位；
6. 第二轮修正优先修位置、比例、密度和层级，而不是只补对象。

这一步之后，技能才从"能生成"开始向"像复刻"靠近。

---

五、第四阶段踩坑：可编辑与保真之间，不能走极端

在技能设计过程中，我还踩过一个反向坑：

为了避免贴图，我一度过度强调"所有元素都要原生可编辑"。

结果模型开始把复杂图标、人物、设备、UI 截图都用基础几何图形硬画出来。

比如：

• 医生图标变成几个圆圈加线条；
• 盾牌图标变成一个粗糙多边形；
• 设备图变成矩形盒子；
• 复杂 UI 被简化成几个色块；
• 原本精致的小图标变成抽象派符号。

这当然"可编辑"，但视觉完全不像。

所以我后来形成了一个更务实的判断：

可编辑不是绝对原生绘制，保真也不是整体截图。真正需要的是对象分层。

对象实现分层

对象类型	推荐实现方式
普通文字、标题、标签	PPT 文本框
矩形、圆形、线条、箭头、边框	PPT 原生对象
表格、流程、卡片结构	PPT 原生 shape/line 拆开做
背景浅纹理、透明斜线、阴影	原生 shape/line + 低透明度
通用业务/医疗小图标	图标库近似图标转透明 PNG，单图标一对象
简单符号图标	PPT 原生 shape 或组合 shape
特殊复杂图标、Logo	对象级局部素材或透明 PNG
照片、设备图、真实 UI、人物插图	对象级局部裁图
含文字的大内容区	必须拆开，不能整体裁图
图标组、带文字卡片、流程节点	必须拆开，不能一整块截图

这套分层解决了两个极端：

• 不为了保真而整页/整块贴图；
• 不为了可编辑而把复杂视觉对象画丑。

尤其是小图标，我现在更倾向于让模型使用语义接近的图标素材，而不是逐笔手绘。因为图标不是页面的核心编辑内容，保持视觉语义和尺寸一致，比强行可编辑更重要。

---

六、大模型在复杂任务执行中最容易踩的坑

结合这次技能设计，我总结出一些大模型在复杂任务中非常典型的执行倾向。

1. 它会天然走最低成本路径

如果可以 OCR，它就 OCR。

如果可以贴图，它就贴图。

如果可以套模板，它就套模板。

如果可以写失败报告，它就写失败报告。

不要假设模型会自动选择"最符合你真实目标"的路径。

它更可能选择"最容易生成、最容易解释、最容易过检查"的路径。

避坑建议：

• 少堆禁止项；
• 多设计正向路径；
• 把施工顺序写清楚；
• 用过程约束减少捷径空间；
• 不要只检查结果文件是否存在。

---

2. 它会面向审计，而不是面向交付

如果你把审计规则写得太详细，模型会开始研究如何通过审计。

例如：

• 禁止整页图，它就分块图；
• 要有文本框，它就叠 OCR 文本框；
• 要有对象清单，它就写形式化清单；
• 要有状态文件，它就写一个漂亮的 status.json；
• 要有 not_pass，它就把困难页标成 not_pass。

避坑建议：

• 审计规则尽量后置；
• 施工提示不要围绕 gate/blocker 展开；
• 审计只防灾难型失败，不要成为模型的任务目标；
• 质量标准要体现在施工路径里，而不是只体现在检查项里。

---

3. 它会把复杂任务降级成"合理失败"

复杂任务中，模型很容易输出：

• "该任务难度较高"；
• "建议人工复核"；
• "自动化无法保证完全一致"；
• "先生成参考草稿"；
• "后续可继续优化"。

这些话可能都是真的，但如果它替代了实际施工，就是问题。

避坑建议：

• 不要给太多失败出口；
• 不要把人工复核写成常规路径；
• failed 只能用于工具或脚本真正失败；
• not_pass 必须建立在真实施工之后；
• 复杂任务也要先做，而不是先解释为什么难。

---

4. 它会套模板，尤其在 PPT、文档、图表任务里

大模型非常喜欢把页面抽象成：

• 三栏卡片；
• 四宫格；
• 时间轴；
• 流程图；
• dashboard；
• 标题 + 内容块；
• 背景 + 页脚。

这在重新设计任务里可能是优点，但在复刻任务里是大坑。

因为复刻要的是"这一页具体长什么样"，不是"这一类 PPT 通常怎么排"。

避坑建议：

• 禁止语义模板函数；
• 不要让模型跨页统一风格；
• 每页必须基于源图对象逐项施工；
• 允许识别结构，但不能模板化重绘；
• 代码应以坐标和对象为核心，而不是以通用组件为核心。

---

5. 它会忽略小字、细线、浅色装饰和边缘信息

模型经常漏掉：

• 页脚；
• 注释；
• 角标；
• 浅色线条；
• 背景纹理；
• 小图标；
• 细分隔线；
• 卡片阴影；
• 表格线；
• 小字号说明文字。

这些东西单看不重要，但整体缺失后，页面视觉密度会明显下降。

避坑建议：

• 对象清单必须包含背景装饰、页眉页脚、细线、角标；
• 页面密度下降应视为质量问题；
• 第二轮修正要优先补视觉密度和层级；
• 不要只检查主标题和大块内容。

---

6. 它会把"观察文件"写成形式主义文档

当你要求模型先观察、再执行时，它确实会写观察文件。

但不代表它真的按观察执行。

它可能写出非常漂亮的：

• layout_skeleton；
• visual_calibration；
• object_inventory；
• bbox；
• baseline；
• known_issues。

然后在代码里继续凭感觉画。

避坑建议：

• 要求代码变量显式引用观察文件中的区域和基准线；
• 要求对象清单逐项落地；
• 观察不是交付物，施工结果才是；
• 如果观察和代码脱节，视为执行失败。

---

七、我最终认可的技能设计思路

经过多轮踩坑和修正，我对这类技能设计形成了一个核心判断：

工业级大模型技能不是越复杂越好，而是要把正确路径设计得足够短、足够清晰、足够难以偏离。

1. 极简单页工匠模式

对 Slide-Crafter 来说，最有效的不是多 Agent，不是复杂 Planner，不是全局 Critic，而是：

每次只处理当前页。

观察当前页。

标定当前页。

拆解当前页。

施工当前页。

预览当前页。

对比当前页。

写状态。

立即进入下一页。

不要让模型在中途思考整套工程。

不要让模型评估剩余工作量。

不要让模型讨论是否引入并行。

不要让模型过早进入项目管理视角。

复杂任务不是靠宏观架构堆出来的，而是靠每一个原子任务认真完成累积出来的。

---

2. 单页生命周期固定化

我比较认可的单页目录结构是：

pages/slide_XX/
  source.png
  page_observation.md
  build_slide.py
  slide_XX.pptx
  preview.png
  compare.png
  status.json
  assets/

每个文件职责清楚：

文件	作用
source.png	当前页源图
page_observation.md	当前页视觉标定和对象清单
build_slide.py	当前页自包含施工脚本
slide_XX.pptx	当前页可编辑 PPTX
preview.png	当前页输出预览
compare.png	源图和输出图对比
status.json	当前页状态
assets/	当前页对象级素材

这个结构有几个好处：

• 每页上下文隔离；
• 方便单页重跑；
• 方便定位问题；
• 避免历史产物污染；
• 避免跨页模板化；
• 便于最后合并。

---

3. 技能文档要短，不要写成复盘论文

这次我一个很深的体会是：

复盘文档可以长，但技能执行文档不能长。

长文档里如果塞了太多内容：

• 历史失败案例；
• 禁止项；
• 审计规则；
• 失败出口；
• 兼容路径；
• 多 Agent 架构；
• 人工复核说明；
• 各种 if/else；

模型就会抓不到真正核心，甚至会从里面挑一条最省力的路径执行。

所以，技能文档应该只保留当前正确路径：

• 当前任务是什么；
• 每页怎么处理；
• 每页必须产出什么；
• 什么对象必须原生；
• 什么对象允许对象级素材；
• 什么情况才是 failed；
• 当前页完成后立即下一页。

历史踩坑应该放在维护文档，不应该全部塞进 SKILL.md。

---

4. 正向原则比负向禁止更重要

不要只写：

• 禁止整页贴图；
• 禁止分块贴图；
• 禁止 OCR-only；
• 禁止模板化；
• 禁止跳过复杂页。

更应该写：

• 先视觉标定；
• 再重建结构；
• 再放置文字；
• 再处理对象级复杂素材；
• 再生成预览和对比；
• 再基于差异修正；
• 当前页完成后进入下一页。

禁止项是护栏，正向路径才是道路。

只有护栏没有道路，模型就会沿着护栏找缝隙。

---

八、给其他人在设计技能/提示词时的总结性建议

建议 1：先定义"真实交付物"，不要只定义表面结果

比如"生成 PPT"不够。

要定义清楚：

• 是可编辑 PPT，还是图片型 PPT？
• 哪些对象必须可编辑？
• 哪些对象可以是素材？
• 什么情况算伪交付？
• 什么情况算失败？
• 什么情况算已施工但质量未达标？

如果真实交付物没有定义清楚，模型会选择最容易交差的结果。

---

建议 2：把任务拆成原子生命周期，而不是让模型自由发挥

复杂任务最怕一句话扔给模型：

帮我把这 30 页都处理好。

更好的方式是设计一个固定生命周期：

输入 → 观察 → 标定 → 拆解 → 执行 → 预览 → 对比 → 修正 → 状态 → 下一项

每个原子任务都独立闭环。

不要让模型在大任务中自由决定策略。

---

建议 3：不要过早引入复杂 Agent 架构

很多时候，质量问题不是因为 Agent 不够多，而是因为单个任务的执行路径不够清楚。

多 Agent、Planner、Critic、Supervisor 这些架构听起来高级，但如果基础施工路径不稳，复杂架构只会带来更多逃逸空间。

先把单点任务打磨稳定，再考虑编排。

---

建议 4：审计要有，但不要让模型围着审计做事

审计适合防止灾难型失败，例如：

• 文件打不开；
• 结果为空；
• 整页贴图；
• 分块底图；
• OCR-only；
• 文本乱码；
• 关键结构缺失。

但不要把审计写成施工提示的中心。

模型知道考题太多，就会开始研究如何过题。

---

建议 5：失败出口越多，模型越容易摆烂

对于复杂任务，不要轻易写：

• 如果做不到可以......
• 如果复杂可以......
• 如果不确定可以......
• 可以先输出草稿......
• 可以建议人工处理......

这些话对人类是风险控制，对模型可能是退出许可。

更好的写法是：

• 先完成真实施工；
• 无法完美时记录差异；
• 工具失败才 failed；
• 质量不足但已施工才 not_pass；
• 不允许用解释替代执行。

---

建议 6：把"观察"变成"执行约束"

很多技能都会要求模型先分析、再执行。

但分析如果不进入执行，只是形式主义。

可以要求：

• 观察中定义 bbox；
• 代码中使用同名变量；
• 对象清单逐项实现；
• 预览差异必须回到 bbox 和对象清单修正；
• 观察文件不能和最终代码脱节。

---

建议 7：为模型设计"务实分层"，不要逼它走极端

模型很容易走两个极端：

• 为了省事，全都截图；
• 为了可编辑，全都硬画。

所以要提前定义对象分层：

• 哪些必须原生；
• 哪些可以素材；
• 素材粒度到什么级别；
• 哪些绝不能整体裁图；
• 哪些差异可以接受；
• 哪些差异必须修。

边界越清楚，模型越不容易走偏。

---

建议 8：不要把历史复盘全文塞进技能说明

复盘是给维护者看的。

技能说明是给执行者看的。

两者应该分开：

• 复盘文档：记录为什么这么设计、踩过哪些坑、后续怎么维护；
• 技能文档：只保留当前正确路径、执行纪律、输入输出和质量边界。

否则模型会在长文档里迷路。

---

九、复杂任务执行的闭坑指南

下面是我整理的一份快速检查清单。只要看到这些现象，就说明模型可能已经走偏。

1. 看到这些行为，要警惕模型在偷懒

• 直接整页贴图；
• 把页面切成多块拼回去；
• 用 OCR 文本框替代页面施工；
• 大量使用通用模板卡片；
• 多页长得越来越像；
• 复杂区域被整块截图；
• 页面只有文字，没有结构；
• 图标全部消失；
• 小字和细线大量缺失。

2. 看到这些话术，要警惕模型在摆烂

• "该任务复杂度较高"；
• "建议人工复核"；
• "建议后续优化"；
• "可以先生成参考草稿"；
• "剩余页面较多，建议分批处理"；
• "建议引入多 Agent 并行"；
• "当前自动化难以保证完全一致"。

这些话不是不能说，但如果它们出现在执行还没完成之前，就很危险。

3. 看到这些文件，要检查是否形式合规但质量不合格

• 有 page_observation.md，但 PPT 位置仍然漂移；
• 有 status.json，但页面主体没施工；
• 有很多文本框，但没有 shape/line；
• 有 assets/，但里面是大区域截图；
• 有 compare.png，但没有基于差异修正；
• 有 not_pass，但实际只是 OCR 草稿。

4. 看到这些视觉结果，要进入第二轮修正

• 位置明显偏移；
• 比例明显不对；
• 视觉密度明显下降；
• 背景装饰过重；
• 标题层级不对；
• 文字重叠或溢出；
• 重要对象遗漏；
• 流程线关系错误；
• 图标过度手绘导致不像；
• 内容区被图片替代。

第二轮修正不应该只补几个字，而应该优先修：

• 坐标；
• 比例；
• 间距；
• 层级；
• 密度；
• 背景轻重；
• 对象完整度。

---

十、这次技能设计给我的最大启发

这次经历让我对大模型技能设计有了一个更现实的理解：

大模型不是一个稳定的自动化脚本，也不是一个绝对服从的员工。

它更像一个能力很强、但天然会寻找低成本路径的执行者。

你不能只告诉它目标，还要设计它通往目标的路径，并封住那些看似合理但实际偏离目标的捷径。

所以，设计技能/提示词时，真正重要的不是把要求写得更长，而是把执行路径设计得更确定。

我的最终总结是：

1. 复杂任务要原子化。
2. 单步流程要固定化。
3. 提示词要短而硬。
4. 少写禁止项，多写正向路径。
5. 少给失败出口，多要求真实施工。
6. 审计要后置，不要变成施工目标。
7. 观察要进入代码，不要停留在文档。
8. 可编辑和保真要分层平衡。
9. 不要让模型过度感知剩余工作量。
10. 每次发现新型偷懒，不要急着补丁式封堵，而要回到正向原则重新收紧路径。

---

结语：真正要驯服的不是模型能力，而是模型的执行倾向

Slide-Crafter 这个技能的设计过程，表面上是在解决"如何把 PPT 图片复刻成可编辑 PPTX"。

但更深一层看，它其实是在解决一个更通用的问题：

当大模型面对复杂、重复、长链路、高保真任务时，如何让它持续沿着正确路径执行，而不是走向低成本捷径、形式合规、模板化、失败报告和审计规避？

这也是未来很多大模型技能都会遇到的问题。

最后我对这类技能设计的判断是：

不要幻想一个更庞大的提示词能解决所有问题。

真正有效的是：把手工流程拆成稳定的原子任务，把每个任务的正确路径写短、写清楚、写硬，然后让模型一页一页、一项一项、少废话地执行。

对 Slide-Crafter 来说，它的核心不是 OCR，不是 gate，不是多 Agent，不是模板，也不是审计报告。

它真正的核心只有一句话：

每页独立观察，按原图对象施工；简单对象可编辑，复杂对象保真；先结构，后文字；做完当前页，立即下一页。