agent 是智能体的意思，什么是智能体呢，为啥不叫AI了啊，也不叫大模型了，其实这并不是孤立的概念，AI中文就是人工智能，英文全称：Artificial Intelligence，其实就是计算机科学的一个分支，用来研究开发模拟，延伸人的理论方法技术和应用研究。大模型是ai具象化的技术产品，大模型还分了LLM语言大模型、VLM视觉大模型、MLLM多模态、技术上又出现了很多细节，比如混合专家模型-MOE。 MCP 是定的ai识别的上下文协议，用来，调用外部的服务器，返回固定内容信息的一个规则，大家都用这个规则，不就方便了ai调用外部工具获取信息了。方便打通不同企业数据库和ai的交互。 tools 就是工具的意思，这里和mcp紧密相连，tools泛指一类工具，遵循的上下文协议也未必是mcp。方便ai通过这个工具进行获取信息。 plugin是插件的意思，就是个扩展包，这不是ai独有的概念，浏览器有插件，任何应用都可能有插件，一个插件里面东西就多了，可以包含skill，agents，hooks，mcp severs等内容。 prompt是提示词的意思，大模型学的东西多了，大模型要在知识汪洋中预测你想要的下一个词，简直不要太难，那么就帮她缩小范围降低幻觉，那就是定人物，定任务范围，定目标，这样将结合以上的信息，进行数据处理，就大大降低了，大模型胡说八道的可能性。大模型本身就是个统计学问题，根本不具备任何智慧，和反思能力，并非动态进化的，而是提前通过人类社会无数的现有文档，向量化，然后通过多维向量的训练出来的，一个具备无数维度的数学矩阵，通过通过上下文的切割成token又称词元，一个词元就是一个数字，多个词元就组成了一个数学矩阵，将这个数学矩阵扔到transform架构的数学矩阵中。我也不知道是不是百亿参数是不是也决定了词元的数量呢，会影响回应呢？ workflow就是工作流，针对一项工作设计的工作流程，使其完成特定的任务，取代繁重的工作。 hook钩子的意思，什么是钩子啊就是，当执行到特定情况或者涉及特殊判断的时候就会触发的程序，相当于一个钩子，勾住了你的工作流，在特定情况下触发，进而保证进程的稳定和顺利。 skill技能的意思，技能可以是一个md说明的工作文档，也可以是md说明文档加一些小程序、或者一些模板的综合体，目标就是让大模型能按你的md说明文档进行工作。 harness就是一个工作台，工作台上啥也有，自由搭配，想用啥就用啥，比如有plugin、tools、prompt、workflow、hook、skill、和设定好的agent。 AI / 人工智能 └── 大模型 / LLM / VLM / MLLM └── Agentic System / 智能体系统 ├── Prompt：给模型的指令 ├── Context：当前任务上下文 ├── Memory：可长期保存或检索的历史信息 ├── Tools：模型可调用的外部能力 │ └── MCP：连接 tools / resources / prompts 的标准协议之一 ├── Workflow：预设流程 ├── Hook：生命周期触发器 ├── Skill：可复用能力包 ├── Plugin：可安装扩展包 └── Harness：运行框架 / 执行外壳 agent 是配置了 instructions、tools，以及可选运行行为的 LLM MCP Server 可以向 AI 应用暴露 resources、prompts 和 tools。这样不同 AI 应用和不同外部系统之间就不用每次都重新写一套私有接口。 Tool：一个具体能力 MCP Tool：通过 MCP 协议暴露出来的 tool MCP Server：把一组 tools / resources / prompts 提供给 AI 应用 Agent：根据任务需要决定是否调用这些工具 plugin 可能包含 tools、skills、agents、hooks、MCP servers 等内容。简单说，plugin 是“打包和分发能力”的方式。 prompt 帮模型缩小范围，降低幻觉。这个是对的。OpenAI 文档也把 prompt engineering 描述为编写有效指令，让模型更稳定地产生符合要求的内容。 大模型本质上是通过大量数据训练出来的神经网络，它没有人类意义上的主观意识，也不会在普通对话中自动修改自己的模型参数。它的回答来自当前输入、上下文、训练得到的参数，以及推理时的生成过程。我们看到的“推理”“反思”“自我检查”，更多是模型在特定提示、上下文或工具流程下表现出来的能力，而不是人类式的自我意识。 Token：文本被切分后的处理单位。 Token ID：token 被映射成的数字编号。 Embedding：token ID 进入模型后对应的向量表示。 Parameter：模型训练出来的权重和偏置。 Context window：一次输入/输出能处理的 token 上限。 Training tokens：训练时看过的数据 token 数量。 Vocabulary size：分词器支持的 token 种类数量。 文本会先被 tokenizer 切成 token，再映射成 token ID。模型会把 token ID 转成向量表示，也就是 embedding，然后送入 Transformer 网络中计算。Transformer 通过注意力机制和多层神经网络，结合上下文预测后续 token。参数量指的是模型内部训练出来的权重数量，和输入 token 数不是同一个概念。 Workflow 是预先设计好的流程。它强调“步骤固定、路径清楚、可控性强”。比如先读订单，再判断退款规则，再调用退款接口，再发送通知。workflow 里可以用大模型，也可以不用大模型。它和 agent 的区别是：workflow 的路径主要由人或程序提前写好；agent 的路径更多由模型根据目标和中间结果动态决定。 Anthropic 对这个区别说得很清楚：workflows 是 LLM 和工具通过预定义代码路径编排；agents 则是 LLM 动态决定自己的流程和工具使用。 这个方向对。Anthropic 的 Agent Skills 文档也把 skill 描述为模块化能力包，包含 instructions、metadata 和可选资源，比如 scripts、templates，Claude 会在相关任务中自动使用。 另一个官方指南也说 Skills 可以是由 instructions、scripts、resources 组成的文件夹 Context：这次对话/这次任务临时放进来的信息。 Memory：跨会话保存、以后还能拿出来用的信息。 Context 是模型当前这次任务能看到的信息，比如用户问题、系统指令、聊天历史、检索到的文档、工具返回结果等。Memory 是被长期保存、之后还能被取出来的信息，比如用户偏好、项目背景、历史决策、常用规则等。Memory 不是模型参数本身发生了变化，而是系统把相关历史信息保存下来，在需要时重新塞回 context。 5 个帖子 - 4 位参与者 阅读完整话题
请问fable跑了一半被限流中断了，当时s去save了一下工作流。之后能直接model切4.8恢复继续吗 1 个帖子 - 1 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 CainFlow 项目背景 没找到比较好用的调用API进行生图的节点式的工具，很多在线的画布都不支持设置API，还有一些个人制作的软件感觉操作手感怪怪的 有一些是体积大，有一些是卡顿，索性使唤AI开发了一个。 项目简介 CainFlow 是一款受 ComfyUI 启发的轻量级节点式的调用API的绘图工具。前端用的js和css，后端用python 作用： 支持google和openai两种API格式的图片生成或者对话 有图片对比 良好的历史记录功能 有自动重试功能 完成后可以有音效提示 节点式操作 可以搭建属于自己的工作流 有一定的视频生成能力（测试的比较少） 好看的界面，粉色主题 本地保存工作流与历史数据，默认不依赖云端托管 内置工作流管理、媒体恢复、下载、更新和日志能力 提供 Windows 和macos两个版本 项目本身还有很多可以打磨和优化的空间，欢迎感兴趣的大佬一起探讨、指正。 项目开源地址： GitHub - RingoCaviar/CainFlow: 节点式简易本地API请求画图工具 · GitHub Readme已添加友链 1 个帖子 - 1 位参与者 阅读完整话题
✦ ultracode · xhigh effort + dynamic workflows for maximum thoroughness 拉满测试一下能力，结果看了半天项目，改了不到 10 行代码就冷却了 🤡
分享个自己做的东西。 问题 用 AI 写代码越来越爽，但也越来越烦。主要几个痛点： 1. 你变成了人肉 QA Claude 说"搞定了"，你一跑全是 bug 。然后进入死循环：测→报→修→测→报→修…… 明明是让它帮你省时间的，结果你的时间全花在当测试员上了。 2. 完全黑盒 让它搞个复杂点的东西，跑了 20 分钟，你完全不知道它到哪了、在干什么、卡住了没有。 3. 失忆 换个 session 、compact 一下、context 太长被截断——它就忘了项目是什么、之前做了什么决定、代码为什么这么写。下次对话从零开始解释。 4. 偷工减料 你让它写个完整功能，它可能跳过测试、不做错误处理、架构随便搞。你不盯着它就不老实。 我的方案 拿 Claude Code 的 dynamic workflow 做了个强制流水线。你给一句话需求，它必须走完 9 个阶段才交付： /lightsout 用 Express + SQLite + React 做个看板应用，支持拖拽、标签、到期提醒 然后它自动跑： 需求编写 → 独立 agent 审查（不过就打回重写） 交互设计 → 独立 agent 审查 技术架构 → 独立 agent 审查 一致性检查 → 三份文档互相对不上的地方找出来修掉 测试用例设计 → 写代码之前先把测试想清楚 写代码 → 自主决定要不要拆分并行（全栈项目自动拆前后端） QA → 跑测试，没过就自己修，最多 5 轮 E2E 验证 → 真的把应用跑起来试 最终检查 → 需求文档 vs 实际代码逐条对比，有遗漏就补 全程你不需要介入。跑完之后你拿到的是： src/ # 能跑的代码 tests/ # 测试全过 docs/ spec.md # 产品需求（每个功能的场景、错误处理都写了） design.md # 交互设计 architecture.md # 技术架构（ ADR 、模块划分、技术选型理由） test-cases.md # 测试设计 这些文档是项目的"记忆"——下次开新 session ，agent 读一遍 docs/ 就知道项目全貌，不用你重新解释。 核心设计 写的人和审的人必须是不同 agent 。 自己审自己肯定放水。拆开之后质量真的不一样——reviewer 会挑出 writer 自己看不到的问题。 文档先行，代码最后。 不是先写代码再补文档，而是需求、设计、架构全部写完审完了再动手。这样写出来的代码有据可依，测试有的放矢。 代码阶段自己决定策略。 简单项目（比如命令行工具）一个 agent 自己 TDD 搞定。复杂项目（全栈应用）它会自动拆分模块，先搞 shared types ，然后前后端并行开发，最后自己跑集成测试。 每个环节自带修复循环。 审查没过？打回重写。测试挂了？自己修。最多 5 轮。不需要你介入指挥。 实测数据 跑了 4 个全新项目： 项目 类型 测试数 结果 批量文件重命名工具 Python CLI 67 个测试 一次通过 实时 Markdown 编辑器 Express + React + WebSocket 66 个测试 1 轮修复后通过 个人记账 API + Dashboard FastAPI + React 50 个测试 一次通过 看板应用 Express + React + 拖拽 — 一次通过 每个项目都手动验证过——真的能跑，功能正常。 代价 本质上这东西是拿 token 换你的时间和精力。每次跑 30-50 个 agent call ，45 分钟到 2 小时不等。如果这个 token 开销让你肉疼，那可能不适合你。但如果你有公司报销，或者你觉得自己的注意力比 token 值钱——与其花一小时盯着它干活、测 bug 、来回沟通，不如让它自己跑完所有环节，你回来看成品——那这个 trade-off 就很值。 Repo GitHub: https://github.com/DreamChaserEric/claude-lights-out 一行安装： curl -fsSL https://raw.githubusercontent.com/DreamChaserEric/claude-lights-out/main/install.sh | bash 需要 Claude Code 且支持 workflow 功能。 欢迎反馈。
✦ ultracode · xhigh effort + dynamic workflows for maximum thoroughness 拉满测试一下能力，结果看了半天项目，改了不到 10 行代码就冷却了 🤡
分享个自己做的东西。 问题 用 AI 写代码越来越爽，但也越来越烦。主要几个痛点： 1. 你变成了人肉 QA Claude 说"搞定了"，你一跑全是 bug 。然后进入死循环：测→报→修→测→报→修…… 明明是让它帮你省时间的，结果你的时间全花在当测试员上了。 2. 完全黑盒 让它搞个复杂点的东西，跑了 20 分钟，你完全不知道它到哪了、在干什么、卡住了没有。 3. 失忆 换个 session 、compact 一下、context 太长被截断——它就忘了项目是什么、之前做了什么决定、代码为什么这么写。下次对话从零开始解释。 4. 偷工减料 你让它写个完整功能，它可能跳过测试、不做错误处理、架构随便搞。你不盯着它就不老实。 我的方案 拿 Claude Code 的 dynamic workflow 做了个强制流水线。你给一句话需求，它必须走完 9 个阶段才交付： /lightsout 用 Express + SQLite + React 做个看板应用，支持拖拽、标签、到期提醒 然后它自动跑： 需求编写 → 独立 agent 审查（不过就打回重写） 交互设计 → 独立 agent 审查 技术架构 → 独立 agent 审查 一致性检查 → 三份文档互相对不上的地方找出来修掉 测试用例设计 → 写代码之前先把测试想清楚 写代码 → 自主决定要不要拆分并行（全栈项目自动拆前后端） QA → 跑测试，没过就自己修，最多 5 轮 E2E 验证 → 真的把应用跑起来试 最终检查 → 需求文档 vs 实际代码逐条对比，有遗漏就补 全程你不需要介入。跑完之后你拿到的是： src/ # 能跑的代码 tests/ # 测试全过 docs/ spec.md # 产品需求（每个功能的场景、错误处理都写了） design.md # 交互设计 architecture.md # 技术架构（ ADR 、模块划分、技术选型理由） test-cases.md # 测试设计 这些文档是项目的"记忆"——下次开新 session ，agent 读一遍 docs/ 就知道项目全貌，不用你重新解释。 核心设计 写的人和审的人必须是不同 agent 。 自己审自己肯定放水。拆开之后质量真的不一样——reviewer 会挑出 writer 自己看不到的问题。 文档先行，代码最后。 不是先写代码再补文档，而是需求、设计、架构全部写完审完了再动手。这样写出来的代码有据可依，测试有的放矢。 代码阶段自己决定策略。 简单项目（比如命令行工具）一个 agent 自己 TDD 搞定。复杂项目（全栈应用）它会自动拆分模块，先搞 shared types ，然后前后端并行开发，最后自己跑集成测试。 每个环节自带修复循环。 审查没过？打回重写。测试挂了？自己修。最多 5 轮。不需要你介入指挥。 实测数据 跑了 4 个全新项目： 项目 类型 测试数 结果 批量文件重命名工具 Python CLI 67 个测试 一次通过 实时 Markdown 编辑器 Express + React + WebSocket 66 个测试 1 轮修复后通过 个人记账 API + Dashboard FastAPI + React 50 个测试 一次通过 看板应用 Express + React + 拖拽 — 一次通过 每个项目都手动验证过——真的能跑，功能正常。 代价 本质上这东西是拿 token 换你的时间和精力。每次跑 30-50 个 agent call ，45 分钟到 2 小时不等。如果这个 token 开销让你肉疼，那可能不适合你。但如果你有公司报销，或者你觉得自己的注意力比 token 值钱——与其花一小时盯着它干活、测 bug 、来回沟通，不如让它自己跑完所有环节，你回来看成品——那这个 trade-off 就很值。 Repo GitHub: https://github.com/DreamChaserEric/claude-lights-out 一行安装： curl -fsSL https://raw.githubusercontent.com/DreamChaserEric/claude-lights-out/main/install.sh | bash 需要 Claude Code 且支持 workflow 功能。 欢迎反馈。
✦ ultracode · xhigh effort + dynamic workflows for maximum thoroughness 拉满测试一下能力，结果看了半天项目，改了不到 10 行代码就冷却了 🤡
分享个自己做的东西。 问题 用 AI 写代码越来越爽，但也越来越烦。主要几个痛点： 1. 你变成了人肉 QA Claude 说"搞定了"，你一跑全是 bug 。然后进入死循环：测→报→修→测→报→修…… 明明是让它帮你省时间的，结果你的时间全花在当测试员上了。 2. 完全黑盒 让它搞个复杂点的东西，跑了 20 分钟，你完全不知道它到哪了、在干什么、卡住了没有。 3. 失忆 换个 session 、compact 一下、context 太长被截断——它就忘了项目是什么、之前做了什么决定、代码为什么这么写。下次对话从零开始解释。 4. 偷工减料 你让它写个完整功能，它可能跳过测试、不做错误处理、架构随便搞。你不盯着它就不老实。 我的方案 拿 Claude Code 的 dynamic workflow 做了个强制流水线。你给一句话需求，它必须走完 9 个阶段才交付： /lightsout 用 Express + SQLite + React 做个看板应用，支持拖拽、标签、到期提醒 然后它自动跑： 需求编写 → 独立 agent 审查（不过就打回重写） 交互设计 → 独立 agent 审查 技术架构 → 独立 agent 审查 一致性检查 → 三份文档互相对不上的地方找出来修掉 测试用例设计 → 写代码之前先把测试想清楚 写代码 → 自主决定要不要拆分并行（全栈项目自动拆前后端） QA → 跑测试，没过就自己修，最多 5 轮 E2E 验证 → 真的把应用跑起来试 最终检查 → 需求文档 vs 实际代码逐条对比，有遗漏就补 全程你不需要介入。跑完之后你拿到的是： src/ # 能跑的代码 tests/ # 测试全过 docs/ spec.md # 产品需求（每个功能的场景、错误处理都写了） design.md # 交互设计 architecture.md # 技术架构（ ADR 、模块划分、技术选型理由） test-cases.md # 测试设计 这些文档是项目的"记忆"——下次开新 session ，agent 读一遍 docs/ 就知道项目全貌，不用你重新解释。 核心设计 写的人和审的人必须是不同 agent 。 自己审自己肯定放水。拆开之后质量真的不一样——reviewer 会挑出 writer 自己看不到的问题。 文档先行，代码最后。 不是先写代码再补文档，而是需求、设计、架构全部写完审完了再动手。这样写出来的代码有据可依，测试有的放矢。 代码阶段自己决定策略。 简单项目（比如命令行工具）一个 agent 自己 TDD 搞定。复杂项目（全栈应用）它会自动拆分模块，先搞 shared types ，然后前后端并行开发，最后自己跑集成测试。 每个环节自带修复循环。 审查没过？打回重写。测试挂了？自己修。最多 5 轮。不需要你介入指挥。 实测数据 跑了 4 个全新项目： 项目 类型 测试数 结果 批量文件重命名工具 Python CLI 67 个测试 一次通过 实时 Markdown 编辑器 Express + React + WebSocket 66 个测试 1 轮修复后通过 个人记账 API + Dashboard FastAPI + React 50 个测试 一次通过 看板应用 Express + React + 拖拽 — 一次通过 每个项目都手动验证过——真的能跑，功能正常。 代价 本质上这东西是拿 token 换你的时间和精力。每次跑 30-50 个 agent call ，45 分钟到 2 小时不等。如果这个 token 开销让你肉疼，那可能不适合你。但如果你有公司报销，或者你觉得自己的注意力比 token 值钱——与其花一小时盯着它干活、测 bug 、来回沟通，不如让它自己跑完所有环节，你回来看成品——那这个 trade-off 就很值。 Repo GitHub: https://github.com/DreamChaserEric/claude-lights-out 一行安装： curl -fsSL https://raw.githubusercontent.com/DreamChaserEric/claude-lights-out/main/install.sh | bash 需要 Claude Code 且支持 workflow 功能。 欢迎反馈。
分享个自己做的东西。 问题 用 AI 写代码越来越爽，但也越来越烦。主要几个痛点： 1. 你变成了人肉 QA Claude 说"搞定了"，你一跑全是 bug 。然后进入死循环：测→报→修→测→报→修…… 明明是让它帮你省时间的，结果你的时间全花在当测试员上了。 2. 完全黑盒 让它搞个复杂点的东西，跑了 20 分钟，你完全不知道它到哪了、在干什么、卡住了没有。 3. 失忆 换个 session 、compact 一下、context 太长被截断——它就忘了项目是什么、之前做了什么决定、代码为什么这么写。下次对话从零开始解释。 4. 偷工减料 你让它写个完整功能，它可能跳过测试、不做错误处理、架构随便搞。你不盯着它就不老实。 我的方案 拿 Claude Code 的 dynamic workflow 做了个强制流水线。你给一句话需求，它必须走完 9 个阶段才交付： /lightsout 用 Express + SQLite + React 做个看板应用，支持拖拽、标签、到期提醒 然后它自动跑： 需求编写 → 独立 agent 审查（不过就打回重写） 交互设计 → 独立 agent 审查 技术架构 → 独立 agent 审查 一致性检查 → 三份文档互相对不上的地方找出来修掉 测试用例设计 → 写代码之前先把测试想清楚 写代码 → 自主决定要不要拆分并行（全栈项目自动拆前后端） QA → 跑测试，没过就自己修，最多 5 轮 E2E 验证 → 真的把应用跑起来试 最终检查 → 需求文档 vs 实际代码逐条对比，有遗漏就补 全程你不需要介入。跑完之后你拿到的是： src/ # 能跑的代码 tests/ # 测试全过 docs/ spec.md # 产品需求（每个功能的场景、错误处理都写了） design.md # 交互设计 architecture.md # 技术架构（ ADR 、模块划分、技术选型理由） test-cases.md # 测试设计 这些文档是项目的"记忆"——下次开新 session ，agent 读一遍 docs/ 就知道项目全貌，不用你重新解释。 核心设计 写的人和审的人必须是不同 agent 。 自己审自己肯定放水。拆开之后质量真的不一样——reviewer 会挑出 writer 自己看不到的问题。 文档先行，代码最后。 不是先写代码再补文档，而是需求、设计、架构全部写完审完了再动手。这样写出来的代码有据可依，测试有的放矢。 代码阶段自己决定策略。 简单项目（比如命令行工具）一个 agent 自己 TDD 搞定。复杂项目（全栈应用）它会自动拆分模块，先搞 shared types ，然后前后端并行开发，最后自己跑集成测试。 每个环节自带修复循环。 审查没过？打回重写。测试挂了？自己修。最多 5 轮。不需要你介入指挥。 实测数据 跑了 4 个全新项目： 项目 类型 测试数 结果 批量文件重命名工具 Python CLI 67 个测试 一次通过 实时 Markdown 编辑器 Express + React + WebSocket 66 个测试 1 轮修复后通过 个人记账 API + Dashboard FastAPI + React 50 个测试 一次通过 看板应用 Express + React + 拖拽 — 一次通过 每个项目都手动验证过——真的能跑，功能正常。 代价 本质上这东西是拿 token 换你的时间和精力。每次跑 30-50 个 agent call ，45 分钟到 2 小时不等。如果这个 token 开销让你肉疼，那可能不适合你。但如果你有公司报销，或者你觉得自己的注意力比 token 值钱——与其花一小时盯着它干活、测 bug 、来回沟通，不如让它自己跑完所有环节，你回来看成品——那这个 trade-off 就很值。 Repo GitHub: https://github.com/DreamChaserEric/claude-lights-out 一行安装： curl -fsSL https://raw.githubusercontent.com/DreamChaserEric/claude-lights-out/main/install.sh | bash 需要 Claude Code 且支持 workflow 功能。 欢迎反馈。
✦ ultracode · xhigh effort + dynamic workflows for maximum thoroughness 拉满测试一下能力，结果看了半天项目，改了不到 10 行代码就冷却了 🤡
✦ ultracode · xhigh effort + dynamic workflows for maximum thoroughness 拉满测试一下能力，结果看了半天项目，改了不到 10 行代码就冷却了 🤡
✦ ultracode · xhigh effort + dynamic workflows for maximum thoroughness 拉满测试一下能力，结果看了半天项目，改了不到 10 行代码就冷却了 🤡
近日看到瑞幸上线了Skill, 它做的，就是把「点一杯咖啡」改造成 AI agent 能直接调用的工具。 flowchart A --> 2 个帖子 - 2 位参与者 阅读完整话题
分享个自己做的东西。 问题 用 AI 写代码越来越爽，但也越来越烦。主要几个痛点： 1. 你变成了人肉 QA Claude 说"搞定了"，你一跑全是 bug 。然后进入死循环：测→报→修→测→报→修…… 明明是让它帮你省时间的，结果你的时间全花在当测试员上了。 2. 完全黑盒 让它搞个复杂点的东西，跑了 20 分钟，你完全不知道它到哪了、在干什么、卡住了没有。 3. 失忆 换个 session 、compact 一下、context 太长被截断——它就忘了项目是什么、之前做了什么决定、代码为什么这么写。下次对话从零开始解释。 4. 偷工减料 你让它写个完整功能，它可能跳过测试、不做错误处理、架构随便搞。你不盯着它就不老实。 我的方案 拿 Claude Code 的 dynamic workflow 做了个强制流水线。你给一句话需求，它必须走完 9 个阶段才交付： /lightsout 用 Express + SQLite + React 做个看板应用，支持拖拽、标签、到期提醒 然后它自动跑： 需求编写 → 独立 agent 审查（不过就打回重写） 交互设计 → 独立 agent 审查 技术架构 → 独立 agent 审查 一致性检查 → 三份文档互相对不上的地方找出来修掉 测试用例设计 → 写代码之前先把测试想清楚 写代码 → 自主决定要不要拆分并行（全栈项目自动拆前后端） QA → 跑测试，没过就自己修，最多 5 轮 E2E 验证 → 真的把应用跑起来试 最终检查 → 需求文档 vs 实际代码逐条对比，有遗漏就补 全程你不需要介入。跑完之后你拿到的是： src/ # 能跑的代码 tests/ # 测试全过 docs/ spec.md # 产品需求（每个功能的场景、错误处理都写了） design.md # 交互设计 architecture.md # 技术架构（ ADR 、模块划分、技术选型理由） test-cases.md # 测试设计 这些文档是项目的"记忆"——下次开新 session ，agent 读一遍 docs/ 就知道项目全貌，不用你重新解释。 核心设计 写的人和审的人必须是不同 agent 。 自己审自己肯定放水。拆开之后质量真的不一样——reviewer 会挑出 writer 自己看不到的问题。 文档先行，代码最后。 不是先写代码再补文档，而是需求、设计、架构全部写完审完了再动手。这样写出来的代码有据可依，测试有的放矢。 代码阶段自己决定策略。 简单项目（比如命令行工具）一个 agent 自己 TDD 搞定。复杂项目（全栈应用）它会自动拆分模块，先搞 shared types ，然后前后端并行开发，最后自己跑集成测试。 每个环节自带修复循环。 审查没过？打回重写。测试挂了？自己修。最多 5 轮。不需要你介入指挥。 实测数据 跑了 4 个全新项目： 项目 类型 测试数 结果 批量文件重命名工具 Python CLI 67 个测试 一次通过 实时 Markdown 编辑器 Express + React + WebSocket 66 个测试 1 轮修复后通过 个人记账 API + Dashboard FastAPI + React 50 个测试 一次通过 看板应用 Express + React + 拖拽 — 一次通过 每个项目都手动验证过——真的能跑，功能正常。 代价 本质上这东西是拿 token 换你的时间和精力。每次跑 30-50 个 agent call ，45 分钟到 2 小时不等。如果这个 token 开销让你肉疼，那可能不适合你。但如果你有公司报销，或者你觉得自己的注意力比 token 值钱——与其花一小时盯着它干活、测 bug 、来回沟通，不如让它自己跑完所有环节，你回来看成品——那这个 trade-off 就很值。 Repo GitHub: https://github.com/DreamChaserEric/claude-lights-out 一行安装： curl -fsSL https://raw.githubusercontent.com/DreamChaserEric/claude-lights-out/main/install.sh | bash 需要 Claude Code 且支持 workflow 功能。 欢迎反馈。
分享个自己做的东西。 问题 用 AI 写代码越来越爽，但也越来越烦。主要几个痛点： 1. 你变成了人肉 QA Claude 说"搞定了"，你一跑全是 bug 。然后进入死循环：测→报→修→测→报→修…… 明明是让它帮你省时间的，结果你的时间全花在当测试员上了。 2. 完全黑盒 让它搞个复杂点的东西，跑了 20 分钟，你完全不知道它到哪了、在干什么、卡住了没有。 3. 失忆 换个 session 、compact 一下、context 太长被截断——它就忘了项目是什么、之前做了什么决定、代码为什么这么写。下次对话从零开始解释。 4. 偷工减料 你让它写个完整功能，它可能跳过测试、不做错误处理、架构随便搞。你不盯着它就不老实。 我的方案 拿 Claude Code 的 dynamic workflow 做了个强制流水线。你给一句话需求，它必须走完 9 个阶段才交付： /lightsout 用 Express + SQLite + React 做个看板应用，支持拖拽、标签、到期提醒 然后它自动跑： 需求编写 → 独立 agent 审查（不过就打回重写） 交互设计 → 独立 agent 审查 技术架构 → 独立 agent 审查 一致性检查 → 三份文档互相对不上的地方找出来修掉 测试用例设计 → 写代码之前先把测试想清楚 写代码 → 自主决定要不要拆分并行（全栈项目自动拆前后端） QA → 跑测试，没过就自己修，最多 5 轮 E2E 验证 → 真的把应用跑起来试 最终检查 → 需求文档 vs 实际代码逐条对比，有遗漏就补 全程你不需要介入。跑完之后你拿到的是： src/ # 能跑的代码 tests/ # 测试全过 docs/ spec.md # 产品需求（每个功能的场景、错误处理都写了） design.md # 交互设计 architecture.md # 技术架构（ ADR 、模块划分、技术选型理由） test-cases.md # 测试设计 这些文档是项目的"记忆"——下次开新 session ，agent 读一遍 docs/ 就知道项目全貌，不用你重新解释。 核心设计 写的人和审的人必须是不同 agent 。 自己审自己肯定放水。拆开之后质量真的不一样——reviewer 会挑出 writer 自己看不到的问题。 文档先行，代码最后。 不是先写代码再补文档，而是需求、设计、架构全部写完审完了再动手。这样写出来的代码有据可依，测试有的放矢。 代码阶段自己决定策略。 简单项目（比如命令行工具）一个 agent 自己 TDD 搞定。复杂项目（全栈应用）它会自动拆分模块，先搞 shared types ，然后前后端并行开发，最后自己跑集成测试。 每个环节自带修复循环。 审查没过？打回重写。测试挂了？自己修。最多 5 轮。不需要你介入指挥。 实测数据 跑了 4 个全新项目： 项目 类型 测试数 结果 批量文件重命名工具 Python CLI 67 个测试 一次通过 实时 Markdown 编辑器 Express + React + WebSocket 66 个测试 1 轮修复后通过 个人记账 API + Dashboard FastAPI + React 50 个测试 一次通过 看板应用 Express + React + 拖拽 — 一次通过 每个项目都手动验证过——真的能跑，功能正常。 代价 本质上这东西是拿 token 换你的时间和精力。每次跑 30-50 个 agent call ，45 分钟到 2 小时不等。如果这个 token 开销让你肉疼，那可能不适合你。但如果你有公司报销，或者你觉得自己的注意力比 token 值钱——与其花一小时盯着它干活、测 bug 、来回沟通，不如让它自己跑完所有环节，你回来看成品——那这个 trade-off 就很值。 Repo GitHub: https://github.com/DreamChaserEric/claude-lights-out 一行安装： curl -fsSL https://raw.githubusercontent.com/DreamChaserEric/claude-lights-out/main/install.sh | bash 需要 Claude Code 且支持 workflow 功能。 欢迎反馈。
✦ ultracode · xhigh effort + dynamic workflows for maximum thoroughness 拉满测试一下能力，结果看了半天项目，改了不到 10 行代码就冷却了 🤡
分享个自己做的东西。 问题 用 AI 写代码越来越爽，但也越来越烦。主要几个痛点： 1. 你变成了人肉 QA Claude 说"搞定了"，你一跑全是 bug 。然后进入死循环：测→报→修→测→报→修…… 明明是让它帮你省时间的，结果你的时间全花在当测试员上了。 2. 完全黑盒 让它搞个复杂点的东西，跑了 20 分钟，你完全不知道它到哪了、在干什么、卡住了没有。 3. 失忆 换个 session 、compact 一下、context 太长被截断——它就忘了项目是什么、之前做了什么决定、代码为什么这么写。下次对话从零开始解释。 4. 偷工减料 你让它写个完整功能，它可能跳过测试、不做错误处理、架构随便搞。你不盯着它就不老实。 我的方案 拿 Claude Code 的 dynamic workflow 做了个强制流水线。你给一句话需求，它必须走完 9 个阶段才交付： /lightsout 用 Express + SQLite + React 做个看板应用，支持拖拽、标签、到期提醒 然后它自动跑： 需求编写 → 独立 agent 审查（不过就打回重写） 交互设计 → 独立 agent 审查 技术架构 → 独立 agent 审查 一致性检查 → 三份文档互相对不上的地方找出来修掉 测试用例设计 → 写代码之前先把测试想清楚 写代码 → 自主决定要不要拆分并行（全栈项目自动拆前后端） QA → 跑测试，没过就自己修，最多 5 轮 E2E 验证 → 真的把应用跑起来试 最终检查 → 需求文档 vs 实际代码逐条对比，有遗漏就补 全程你不需要介入。跑完之后你拿到的是： src/ # 能跑的代码 tests/ # 测试全过 docs/ spec.md # 产品需求（每个功能的场景、错误处理都写了） design.md # 交互设计 architecture.md # 技术架构（ ADR 、模块划分、技术选型理由） test-cases.md # 测试设计 这些文档是项目的"记忆"——下次开新 session ，agent 读一遍 docs/ 就知道项目全貌，不用你重新解释。 核心设计 写的人和审的人必须是不同 agent 。 自己审自己肯定放水。拆开之后质量真的不一样——reviewer 会挑出 writer 自己看不到的问题。 文档先行，代码最后。 不是先写代码再补文档，而是需求、设计、架构全部写完审完了再动手。这样写出来的代码有据可依，测试有的放矢。 代码阶段自己决定策略。 简单项目（比如命令行工具）一个 agent 自己 TDD 搞定。复杂项目（全栈应用）它会自动拆分模块，先搞 shared types ，然后前后端并行开发，最后自己跑集成测试。 每个环节自带修复循环。 审查没过？打回重写。测试挂了？自己修。最多 5 轮。不需要你介入指挥。 实测数据 跑了 4 个全新项目： 项目 类型 测试数 结果 批量文件重命名工具 Python CLI 67 个测试 一次通过 实时 Markdown 编辑器 Express + React + WebSocket 66 个测试 1 轮修复后通过 个人记账 API + Dashboard FastAPI + React 50 个测试 一次通过 看板应用 Express + React + 拖拽 — 一次通过 每个项目都手动验证过——真的能跑，功能正常。 代价 本质上这东西是拿 token 换你的时间和精力。每次跑 30-50 个 agent call ，45 分钟到 2 小时不等。如果这个 token 开销让你肉疼，那可能不适合你。但如果你有公司报销，或者你觉得自己的注意力比 token 值钱——与其花一小时盯着它干活、测 bug 、来回沟通，不如让它自己跑完所有环节，你回来看成品——那这个 trade-off 就很值。 Repo GitHub: https://github.com/DreamChaserEric/claude-lights-out 一行安装： curl -fsSL https://raw.githubusercontent.com/DreamChaserEric/claude-lights-out/main/install.sh | bash 需要 Claude Code 且支持 workflow 功能。 欢迎反馈。
✦ ultracode · xhigh effort + dynamic workflows for maximum thoroughness 拉满测试一下能力，结果看了半天项目，改了不到 10 行代码就冷却了 🤡
✦ ultracode · xhigh effort + dynamic workflows for maximum thoroughness 拉满测试一下能力，结果看了半天项目，改了不到 10 行代码就冷却了 🤡