编排层：from-idea-to-personal-site 与 build-personal-site

真实用户通常只会说一句：“帮我做个博客。”

Idea2Site 里真正让整套 skill suite 串起来的是两个编排 skill：

from-idea-to-personal-site
build-personal-site

这两个 skill 很容易被误解成重复。我一开始看也会觉得：怎么两个都是编排？

但往细了看，它们的分工其实非常清楚：

from-idea-to-personal-site：面向用户的端到端入口
build-personal-site：面向当前状态的路由协调器

一个关注“从想法到交付”的完整目标。

一个关注“现在这一步应该调用谁”的局部路由。

1. 为什么需要编排层？

如果只有底层 skill，用户就必须知道自己当前处在哪个阶段。这对真实用户来说不现实。

比如：

风格不清楚，应该用 search-blog-theme；
方向清楚，需要参考，应该用 find-style-references；
原创建站，应该用 make-personal-site；
具体 URL 复刻，应该用 copy-website-style；
替换身份，应该用 personalize-site；
加文章，应该用 add-blog-posts；
小修，应该用 edit-site-part；
检查，应该用 review-static-site；
发布，应该用 publish-static-site。

但真实对话里，用户往往是直接把目标丢出来。

用户通常会这样说：

我想做一个个人博客。
这个网站风格不错，帮我做一个类似的。
我有几篇 Obsidian 笔记，想整理进去。
改完了，发布吧。

这时候就需要编排 skill 来决定路线。这个部分看起来很抽象，但实际非常重要。

编排层的价值就在这里：它减少无意义追问，也减少随便猜 skill 的情况。

有了编排层之后，用户给出目标，系统自己选择最短可靠路径。

2. from-idea-to-personal-site：端到端主入口

from-idea-to-personal-site 是整个项目最用户友好的入口。它处理的是用户一句话丢进来的完整目标。

它处理的是这种请求：

从一个模糊想法、参考 URL、模板、个人材料、文章草稿，走到一个本地验证过的网站，甚至走到线上发布。

它承担编排职责，负责把任务交给对应的子 skill。

它的职责是：

选择并串联子 skill。
每个阶段后检查 gate。
失败后路由到最小负责 skill 修复。
直到达到用户想要的终点。

2.1 默认流程

它的默认流程很完整：

1. Clarify endpoint
2. Choose direction
3. Ground style in references
4. Create or recreate the site
5. Personalize content
6. Add writing
7. Validate
8. Publish or prepare
9. Handoff

每一步都有 gate。这个设计我觉得很像做实验的时候每一阶段都要看结果，不通过就回去修。

比如方向阶段的 gate 是：

direction is concrete enough to build

建站阶段的 gate 是：

required page types exist and navigation points to real pages

内容阶段的 gate 是：

user-provided information appears in intended areas and source/demo residue is gone

验证阶段的 gate 是：

review-static-site has no blockers

发布阶段的 gate 是：

deployment root is correct and live/prepared site uses the right folder

这就是它和普通“流程描述”的区别。它写路线图，也要在每一步判断是否可以继续。

它强调每一步都有完成标准，避免停在“可以先做 A 再做 B”。

2.2 路由快捷方式

实际运行时，它会走快捷路径。

比如：

Vague idea only:
search-blog-theme -> find-style-references -> make-personal-site -> review-static-site

Reference website:
copy-website-style -> personalize-site -> review-static-site

Existing site plus identity:
personalize-site -> review-static-site

Existing site plus articles:
add-blog-posts -> review-static-site

Existing site plus one precise change:
edit-site-part -> affected browser validation

Publish request:
review-static-site -> publish-static-site

这就是“最短可靠路径”的思想。加文章直接走文章导入，发布直接走检查和部署，小改直接走局部编辑。

真正的编排会根据当前输入选对路径。

2.3 One-click defaults

当用户没说清楚时，from-idea-to-personal-site 有一些默认策略。

比如：

默认纯静态 HTML/CSS/JS；
默认输出到明确的本地 site/；
默认第一屏走内容导向，避开营销 landing page；
缺少个人信息时用 placeholder；
原创建站前先找真实参考；
默认 page-relative path；
发布前默认本地验证；
发布平台没有偏好时，优先 Cloudflare Pages 或 GitHub Pages。

这些默认值能减少无意义的追问。

比如用户说：

帮我做一个个人博客。

Agent 可以先按默认策略走，缺少个人信息就用 placeholder，后续再个性化。

2.4 Gate Loop

from-idea-to-personal-site 最重要的是 gate loop：

检查当前阶段 gate
如果通过，继续
如果失败，路由到最小负责 skill
修复
重跑相关验证
继续

比如建站后发现路径错误：

review-static-site -> path blocker

这时回到能修路径的最小 skill，然后再跑受影响检查。

再比如发现用户身份还是 placeholder：

personalize-site

如果文章图片路径错：

add-blog-posts

这就是让流程可修复的关键。

3. build-personal-site：低层路由协调器

build-personal-site 也是编排 skill，但它更像内部调度器。

它可以从中途状态开始，也可以只处理当前这一步。

它处理的是：

当前这个个人站工作流，下一步应该调用哪个 child skill？

比如用户问：

我现在有个 site 文件夹，下一步该干嘛？

这时候不一定要走 from-idea-to-personal-site 的完整流程。因为当前已经进入中途状态。

build-personal-site 可以检查当前状态，然后判断：

如果还有 placeholder，走 personalize-site；
如果有文章材料，走 add-blog-posts；
如果用户要小改，走 edit-site-part；
如果准备发布，走 review-static-site -> publish-static-site；
如果只是方向不清楚，走 search-blog-theme。

3.1 Contract Matrix

build-personal-site 里有一个 child skill contract matrix。

它列出了每个子 skill 的：

required input；
expected output；
success gate；
if gate fails。

比如：

search-blog-theme
输入：用户 taste / purpose / reference
输出：3-5 directions
gate：方向具体到可以 build
失败：继续找参考、收紧 metaphor 或问一个偏好问题

再比如：

review-static-site
输入：static root
输出：findings / fixes / pass-fail
gate：没有 blocker
失败：路由到最小负责 child skill

这个矩阵的作用是让路由摆脱凭感觉的状态，根据每个 skill 的 contract 做决定。否则 Agent 很容易看到一个问题就顺手自己修，结果越修越乱。

3.2 标准流程

build-personal-site 定义了几条标准 pipeline。

Idea To Original Site

适合只有粗略想法的情况：

search-blog-theme
-> find-style-references
-> make-personal-site
-> personalize-site
-> review-static-site

如果用户没提供个人信息，personalize-site 可以跳过或只记录 placeholder。

Reference To Personal Site

适合给了具体 URL、截图、模板：

copy-website-style
-> personalize-site
-> add-blog-posts if needed
-> review-static-site

Content First Blog

适合用户最强输入是文章：

search-blog-theme if no site/theme
-> find-style-references if new visual system needed
-> make-personal-site if no site exists
-> add-blog-posts
-> personalize-site
-> review-static-site

Existing Site Improvement

适合已有站点：

inspect site and EDITING.md
-> personalize-site / add-blog-posts / edit-site-part
-> review-static-site when needed

Publish Ready Site

适合准备发布：

review-static-site
-> fix blockers
-> publish-static-site

这些 pipeline 让不同用户状态都有对应路径。

4. 两个编排 skill 的区别

我一开始也觉得这两个 skill 有点像。

但仔细看，它们解决的是不同层级的问题。

Skill	主要问题	典型场景
`from-idea-to-personal-site`	从用户大目标走到最终交付	“帮我从想法做一个完整博客”
`build-personal-site`	当前状态应该调用哪个 child skill	“我现在有个站，下一步做什么”

from-idea-to-personal-site 更像产品层入口。

它关心终点：

local validated site
publish-ready package
live deployment

build-personal-site 更像工作流 router。

它关心下一步：

search theme?
find references?
build?
copy?
personalize?
add posts?
review?
publish?

这两个分开之后，整个系统更清楚。

用户一上来给完整目标，就用前者。

中途需要判断下一步，就用后者。

5. 编排层的一个例子

用户输入：

我想做一个安静一点的技术博客，有几篇 Markdown，最后希望能发到 Cloudflare Pages。

from-idea-to-personal-site 可以解析出：

目标：完整本地站 + 准备发布
材料：风格偏好 + Markdown
平台：Cloudflare Pages

然后路线是：

search-blog-theme
-> find-style-references
-> make-personal-site
-> add-blog-posts
-> personalize-site if identity material exists
-> review-static-site
-> publish-static-site guidance or deploy

如果 review-static-site 发现：

posts/foo.html image path missing

就回到 add-blog-posts 修文章资产路径。

如果发现：

homepage still says Your Name

就回到 personalize-site。

如果发现：

mobile nav broken

就回到 edit-site-part。

修完再 review。

这就是一个真正的闭环。

6. 编排层最重要的约束

编排层有几个非常重要的原则。

6.1 让编排层保持轻量

from-idea-to-personal-site 和 build-personal-site 负责加载对应 child skill。

这样编排层可以保持轻量。

6.2 按当前目标选择路径

完整流程适合端到端建站，中途任务直接走最短路径。

用户加文章，直接进入 add-blog-posts 和 review。

用户部署，直接进入 review 和 publish-static-site。

用户小改，直接进入 edit-site-part 和受影响验证。

6.3 review 是固定关口

生成、复刻、个性化、文章导入、广泛修改、发布前，都应该 review。

6.4 用户事实来自材料

缺少个人信息时，用 placeholder。

6.5 远程动作先授权

发布、push、建仓库、绑定域名、改 DNS，都必须用户明确授权。

这些原则看起来像安全条款，但它们其实决定了 Agent 的可靠性。尤其是发布和远程操作，必须要这么保守。

7. 小结

编排层是 Idea2Site 从“工具集合”变成“工作流系统”的关键。

from-idea-to-personal-site 负责完整流程，用户给一个目标就能开始。

build-personal-site 负责中途状态，让当前问题回到合适的 child skill。

这两个 skill 把 11 个模块串成了一套可恢复、可验证、可停止的流程。

我觉得它们最重要的价值是：

让 Agent 既会做某一步，也知道下一步该做什么。

这正是很多 Agent 项目里最难的地方。

单个能力本身相对容易，真实任务里的能力选择和失败修复更难。

Idea2Site 的编排层就是为这个问题服务的。