实用指南7 分钟
changes 与 workflow
理解 proposal、worktree、apply 循环、acceptance 与 merge 在日常开发中的配合方式。
一旦你把 change 当作核心工作单元，Conflux 的整体模型就会清晰很多。
change 目录就是契约
在日常使用中，每个 OpenSpec change 基本上由三部分构成契约：
proposal.md：为什么要做这个变更tasks.md：需要完成哪些实现任务specs/.../spec.md：期望的行为或差异
如果这些文件足够明确，acceptance 代理就可以基于事实判定，而不是猜测你的意图。
日常循环
一个常见的操作循环如下：
- 创建或完善 proposal
- 提交 proposal，保证仓库干净
- 运行
cflx或cflx run - 检查 diff、日志和 acceptance verdict
- 决定是 archive、resolve 还是拆分 change
为什么 worktree 很关键
Conflux 使用 git worktree 隔离不同 change。它带来两个非常实际的好处：
- 独立 change 可以并行推进
- 某个 change 失败，也不容易污染主工作区
这正是 Conflux 与单个聊天式编码会话之间的重要区别之一。
实务建议
如果两项工作放在一起会让代码评审很痛苦，它们大概率应该拆成两个 OpenSpec change，也就是两个独立 worktree。
TUI 与 headless 如何选择
如果你想交互式地决定执行什么 change，使用 TUI。
Terminal
cflx如果你已经知道要执行哪个 change，使用 headless 更直接。
Terminal
cflx run cflx run --change add-feature-xacceptance 不是可有可无的装饰
Conflux 明确区分实现角色和 acceptance 角色，这一点非常关键。这样做意味着：
- 实现代理可以更快推进，
- 验收代理可以更保守地判断，
- 最终结论不容易退化成“自己给自己通过”。
如果省略这一步，往往只是把单代理工作流的盲点原样保留下来。
什么时候应该拆分 change
当出现以下情况时，优先考虑拆分：
tasks.md涵盖太多互不相干的范围- acceptance 因不同原因反复失败
- diff 大到人类很难舒适地审阅
- 你希望部分工作先完成并尽快 merge
运维检查点
这些检查能让运行“稳定地无聊”：
| 检查项 | 作用 |
|---|---|
git status 为 clean | 避免无关修改混入 |
| proposal 已提交 | 提高可复现性 |
| tasks 足够具体 | 让 acceptance 有客观依据 |
| change 范围足够窄 | 提升代理专注度与评审质量 |
一次运行结束后
结束后至少问自己三个问题：
- diff 是否满足 proposal 与 tasks 的要求？
- acceptance 失败是因为真实缺陷，还是因为规格写得不够清楚？
- 现在应该 archive / merge，还是拆成 follow-up change？
正是这一步，让 Conflux 从“看起来很酷的演示”变成“真正可运营的开发流程”。