Evilom
73 lines
8.8 KiB
Markdown
73 lines
8.8 KiB
Markdown
# Mx4SwTP4HiQNISkrygQcGk9jnIe
|
||
|
||
Source: https://dianchukeji.feishu.cn/wiki/Mx4SwTP4HiQNISkrygQcGk9jnIe
|
||
|
||
|
||
# 一.工作内容概述
|
||
- 皮肤面板、碎片收集面板UI美术资源产出、替换
|
||
- 修复替换过程发现的一些缺陷与bug
|
||
- 了解Claude Code Workflow功能，并尝试用其进行完整的项目代码审查、修改、验证任务。
|
||
# 二.Claude Code Workflow 相关
|
||
## 概念
|
||
Claude Code Workflow 是 Claude Code 最近更新的一种面向复杂开发任务的流程化执行方式。它通过阶段拆解、任务委托、能力复用和验证闭环，将 Claude Code 从“单次回答问题”扩展为“持续推进任务”的开发协作模式。对于代码审查、项目整改、批量重构、测试补充、自动化验证等任务，Workflow 能够提供更清晰的执行路径和更稳定的过程控制。
|
||
## 启用方式
|
||
- macOS / Linux / WSL / Git Bash：export CLAUDE_CODE_WORKFLOWS=1
|
||
- Windows CMD：set CLAUDE_CODE_WORKFLOWS=1
|
||
- Windows PowerShell：$env:CLAUDE_CODE_WORKFLOWS="1"
|
||
|
||
## 尝试记录
|
||
### 项目框架分析
|
||
尝试使用 Workflow 对项目进行整体代码框架分析。接到需求后，Claude Code将 Workflow 拆成了三个阶段：
|
||
- Structure 阶段：分析项目结构、核心模块、依赖关系
|
||
- Quality 阶段：并行分析代码质量、错误处理、可维护性
|
||
- Report 阶段：生成综合分析报告
|
||
|
||
从执行过程来看，Workflow 会按照预设阶段依次推进。Structure 阶段先分析项目结构，完成后再进入 Quality 阶段，最后生成 Report。
|
||
|
||
完成后，给出了项目概述以及发现的主要问题。从这次分析可以看到，Workflow不会只停留在单点分析，而是能够把结构、质量、问题、建议整合成一个完整结果。
|
||
|
||
### 基于分析结果生成修改计划
|
||
在完成框架分析后，又继续使用 Workflow 根据前面识别出的问题生成修改计划，选择了最主要的7个问题准备进行修复后，Claude Code创建了新的Workflow脚本，分为三个阶段：
|
||
从计划内容来看，Workflow 不只是简单列出问题，而是进一步拆解了每类问题的影响范围、修复顺序和执行依赖。这一步比较明显体现出 Workflow 的优势：它可以把“分析问题”和“生成执行计划”拆成独立阶段，避免 Agent 一边分析一边直接动手修改，导致任务边界不清晰。
|
||
|
||
### 基于修改计划进行全量修改
|
||
确认计划后，继续执行全量修改 Workflow。执行前，Claude Code 展示了完整的分阶段计划，如图：
|
||
|
||
|
||
随后 Workflow 正式启动，进入分阶段执行状态。
|
||
|
||
|
||
第一轮修改后，大部分任务均已完成，但是仍然存在部分遗留的错误或未修改点，这说明 Workflow 虽然能够完成大规模修改，但复杂代码修改后仍然需要进行验证和二次修复步骤。
|
||
之后继续对剩余错误进行多轮修复，直至全部验证通过。
|
||
|
||
|
||
|
||
## 复盘与思考
|
||
这个方式和启用 Agent Team 有什么区别？既然 Agent Team 也可以通过提示词限定流程，那 Workflow 的区别到底在哪里？
|
||
两者真正的差异不在于“能不能规定流程”，而在于**流程约束的确定性来源不同：**
|
||
- Agent Team 的流程约束主要来自提示词。提示词可以写得很详细，但**最终是否严格执行，仍然依赖模型对提示词的理解和执行意愿**。它可能会因为判断某一步不重要而简化，也可能提前进入下一阶段，或者在汇报中说已经完成某一步，但实际上中间产物并不完整。
|
||
- Workflow 则是**用代码定义流程**。也就是说，哪些阶段一定执行、哪些任务并行、哪些任务必须等待前置结果、失败后是否重试，这些都可以写进脚本里。这样一来，**Agent 的自由发挥空间主要被限制在“如何完成当前子任务”上**，而不是“整个流程应该怎么走”上。
|
||
|
||
> :bulb:
|
||
Workflow 的确定性更强，主要强在“执行路径”的确定性，而不是强在“Agent 输出内容”的确定性。
|
||
Workflow 不能保证每个 Agent 的分析结果一定完全正确，也不能保证生成的代码或报告一定完美，但它能更稳定地保证任务按照既定流程推进。这对复杂任务来说很重要，因为复杂任务最怕的不是某个子任务做得不够好，而是整体流程失控，比如跳过分析直接修改、修改后不验证、发现问题后没有进入二次修复等。
|
||
Skill 本身也可以编写脚本，也可以调用 Agent，也可以实现并行、重试、验证等逻辑。既然如此，为什么还需要 Workflow？
|
||
从技术能力上讲，一个足够复杂的 Skill 确实可以实现 Workflow 的很多能力，甚至可以在 Skill 里自己写阶段控制、并行调度、错误处理、预算控制和最终验证。也就是说，Workflow 并不是 Skill 绝对做不到的东西。
|
||
但两者的设计目的不同。Skill 更偏向**能力封装**，它关注的是“某类任务怎么做”；Workflow 更偏向**流程编排**，它关注的是“多个任务之间怎么组织”。如果在 Skill 里实现完整 Workflow，本质上就是把一套编排框架重新写进 Skill 里。这样当然可行，但会让 Skill 本身变得很重，职责也会变得混杂。
|
||
|
||
> :bulb:
|
||
Skill 可以实现 Workflow 的功能，但 Workflow 把复杂任务中的流程控制单独抽象出来，使其更标准、更显式、更适合复用。
|
||
是否可以实现一个和 Workflow 功能完全一致的 Skill？
|
||
技术上可以。只要 Skill 里实现足够多的编排逻辑，它就可以完成 Workflow 做的事情。但这并不意味着 Workflow 没有价值。它的价值不是“能力不可替代”，而是**“流程控制更显式、更统一、更稳定”**。换句话说，**Workflow 不是因为 Skill 做不到才存在，而是因为复杂任务需要一种更适合表达流程的方式。**
|
||
再回顾一次代码审查-修改的过程
|
||
这是一个长链路任务：先分析项目结构，再识别质量问题，再生成修改计划，再分阶段修复，再执行 TypeScript 编译验证和单元测试验证，最后根据残留错误继续修复。这个过程里，真正重要的是阶段顺序和验证闭环。
|
||
如果完全交给 Agent Team，即使提示词写得很详细，也仍然可能出现流程发散的情况。例如，Agent 可能先修了一部分 TypeScript 问题，但没有持续修到 0 错误；可能拆分了大文件，但没有统一修复引用路径；可能清理了 console.log，但没有引入统一 Logger；也可能补了一些测试，但没有最终跑完整验证。**这些问题不是 Agent 不会做，而是当任务链路变长后，单纯依赖自然语言约束容易出现执行不稳定。**
|
||
而 Workflow 在这类任务中更有优势。它可以把复杂任务拆成明确阶段，把每个阶段的目标和输出固定下来，并且在执行后进入验证环节。如果验证失败，再继续进入下一轮修复。这种方式更像是“生产流水线”，而不是一次性让 Agent 自由处理所有问题。
|
||
这次实践中，Workflow 先完成项目分析，再生成修改计划，再执行全量修改，最后继续根据 TypeScript 错误进行二次修复。虽然中间仍然出现了残留错误，但整体流程没有中断，而是继续进入验证和修复闭环。最终彻底完成任务。这个结果说明，**Workflow 的优势并不在于一次执行就完美，而在于它能够支撑复杂任务持续推进到可验证状态。**
|
||
# 三.后续计划
|
||
- 尝试将一些稳定下来的工作流转为Claude Code Workflow,并投入使用
|
||
- 争取明日完成剩余界面的初版UI美术资源产出、替换
|
||
- 持续优化细节表现
|
||
- 体验《佛系消消消》，总结其关卡设计、节奏控制与投放思路；
|
||
- 基于体验结果重新生成并配置关卡，必要时扩充关卡编辑器功能。
|
||
- 持续进行真机测试，排查平台适配问题 |