按改造难度选 starter
哪些 starter 适合直接改，哪些更适合参考结构。
这页回答的是另一个很现实的问题：
“我到底该直接拿这个 starter 改，还是只拿来参考结构？”
一，最适合直接改的 starter
这类 starter 的特点是：
- 主干短
- 责任清楚
- 输入和输出边界清楚
- 审批位置容易理解
最适合直接改的通常是：
| starter | 为什么适合直接改 |
|---|---|
single_step | 主干最短，几乎所有团队都能拿来验证第一条流程 |
approval_flow | 审批逻辑直接，适合挂到自己的业务动作前 |
failure_inbox | 成功 / 失败分叉很好懂 |
review_publish | 审核、批准、返工三段边界清楚 |
artifact_output | 适合多数“先成产物，再交付”的任务 |
daily_ai_brief | 研究到发送这条链很稳定，容易换主题和渠道 |
二，适合“小改”的 starter
这类 starter 一般也能改，但最好只改：
- 输入字段
- 输出字段
- 交付对象
- 一两个中间能力
不建议第一轮就大改结构。
| starter | 建议怎么改 |
|---|---|
browser_desktop_submission_audit | 换 portal、换字段、换证据区，不先乱动主干 |
sales_follow_up | 换 lead 表、换文案目标、换发送渠道 |
customer_knowledge_update | 换知识源、换验证问题、换交付对象 |
support_escalation_resolution | 换 ticket 来源、换 policy 依据、换回复目标 |
三，更适合参考结构，不建议硬改的 starter
这类 starter 往往业务味更重，直接硬改容易出现两个问题：
- 你删了很多东西以后，主干反而更乱；
- 看起来保留了模板，实际上已经比从空白搭还难维护。
更适合“参考结构，不建议硬改”的通常是：
| starter | 为什么 |
|---|---|
fashion_product_try_on | 场景很具体，素材和生成关系比较重 |
product_image_batch | 批量逻辑明确，但改得太多容易失去原本价值 |
xiaohongshu_publish | 平台场景感强，直接硬改到别的平台不一定划算 |
shopify_product_launch | 商品上架语义很重，不适合硬改成泛发布流 |
campaign_launch_pack | 多环节联动多，直接删改容易乱 |
customer_onboarding_pack | 业务上下文浓，适合参考不适合强扭 |
app_capsule_delivery | 更适合明确需要交付壳的团队，不适合拿来做普通 starter |
四，什么时候说明你不该继续硬改 starter
出现下面几种情况时，通常就该停下来，不要再硬改：
- 你已经想删掉一半以上节点；
- 审批位置已经不适合原 starter；
- 输入、输出、交付方式都和原模板差很多；
- 你需要加的分支比原 starter 自带的还多。
这时候更稳的做法是：
- 回到最接近的基础骨架，例如
single_step、approval_flow、review_publish - 或者直接从空白画布重新搭主干
五，一条很实用的经验
如果你不确定一个 starter 到底值不值得改，可以先问：
“我改的是内容，还是改的是骨架？”
如果你主要改的是：
- 主题
- 文案
- 输入字段
- 交付对象
通常还能继续改。
如果你主要改的是：
- 节点主干顺序
- 审批位置
- 成功失败分叉
- 多系统联动关系
那通常已经不是“改模板”，而是在重写流程了。