过去大半年我一直在做一件事把手头所有靠 AI 聊天来完成的工作改造成一个没有对话框的形态。这个项目叫 OpenWand核心理念就一句话——remove chat interface from working with AI。在 Show HN 上发布之后收到的反馈两极分化。有人觉得我在逆潮流而动毕竟行业都在教模型“更会聊天”更多人问得很实在不加聊天框AI 到底该怎么用我先描述一个几乎所有开发者都经历过的场景。以前我用对话式 AI 改代码流程是这样的把报错信息复制进窗口把相关代码片段贴进去等上几十秒拿到一段回复再复制回编辑器跑一遍报新的错再粘回去。一个下午过去我做的事情本质上是在编辑器、终端、浏览器三个窗口之间当人体搬运工。聊天界面真正的问题不是“聊得不够聪明”而是它把工作切成了无数个低效的往返。OpenWand 想要解决的就是这件事让 AI 直接出现在工作现场听懂任务干完活交付一份你可以审查的改动而不是一段需要再次搬运的文字。这篇文章不是项目说明书而是我从聊天式协作转向任务式协作过程中的完整思考包括产品形态、架构取舍和踩坑记录。适合两类人读一类是被 AI 聊天搞得精疲力竭的开发者和内容工作者另一类是正在做 AI 应用、Agent 或效率工具的产品和技术负责人。下面按我真实做这个项目的顺序把问题、答案和经验一个个讲清楚。1. 对话框是 AI 协作里最贵的一笔隐性税决定做 OpenWand 之前我先花了很长一段时间研究“大家到底是怎么用 AI 干活的”。结论有点讽刺绝大多数人用 AI 干活时间不是花在“让 AI 干活”上而是花在“把活描述给 AI”和“把 AI 的结果搬运回工作台”上。聊天框看起来免费实际是效率上最贵的东西。1.1 每一轮对话都在搬运上下文对话式 AI 的能力边界取决于你喂给它的上下文质量。而上下文不会自己出现它需要你手动把报错信息、相关文件、环境变量、依赖版本一项项复制进输入框。这个搬运过程的成本有三层。第一层是时间。一次小任务通常要 3 到 6 轮往返每轮复制粘贴加等待回复少说两分钟一天下来就是半小时到一小时纯搬运。第二层是信息损耗。人一懒就会只贴报错最后三行漏掉完整堆栈只贴函数体漏掉调用方。模型在一个残缺上下文里做判断给出“看起来合理但实际用不了”的答案几乎是必然事件。第三层是注意力。频繁切换窗口会反复打断大脑的工作记忆你本来正在想“这个变量为什么为空”复制完报错再回来思路已经断了一截。任务式交互把这三层成本一起拿掉了。OpenWand 自己去读仓库、看 git 状态、搜索相关文件上下文收集是工具的分内事。用户的角色从“喂数据的人”变成“下指令和做验收的人”。这不是效率提升百分之几十的问题而是协作模式从“人伺候模型”翻转为“模型伺候任务”。1.2 聊天窗口不是工作区聊天界面天然是线性的一条消息、一条回复永远在追加。但真实的工程任务是网状的要同时跟踪多个文件、多个依赖关系、多组测试结果。把网状工作硬塞进线性对话会出现三个典型问题。一是上下文膨胀。对话稍微一长Token 窗口被早期内容占满后来模型越来越“健忘”连自己前面说过的话都要你提醒。二是状态脆弱。你绕了几圈最后说“还是按最开始那个方案做”“最开始”指的是第几条消息人和模型都不一定记得清。三是决策丢失。重要的技术取舍淹没在几百条消息里事后要翻聊天记录才想得起来当时为什么这么做而这个聊天记录往往很快就找不到了。OpenWand 以“任务”作为基本单位每个任务都有明确的目标、范围、产物和验证方式。任务状态可以保存、可以回滚、可以跨天恢复也能导出成一份简单明了的报告。聊天记录是流水账任务报告是档案两者完全不是一回事。1.3 聊天的产物是文字任务的产物是改动这是我下定决心做这个项目的原因。聊天式 AI哪怕回答得再准确交付物始终是“一段话”。拿到这段话之后你还是得自己决定改哪里、怎么改、改完怎么验证。AI 只负责“说”不负责“做”更不对结果负责。任务式交互的输出是 diff是具体文件改动是跑过的测试记录是一份可以 review 的变更集。文字可以天花乱坠改动骗不了人。当 AI 的交付物从“建议”变成“改动”时你对它的审视方式也随之改变不需要再去判断它“说得对不对”直接看它“改得对不对、测没测、有没有动不该动的地方”。这种心态转变带来的信任提升远超我的预期。2. OpenWand 的产品形态任务进来改动出去聊完为什么要去掉对话框再说说去掉之后长什么样。2.1 一条命令一个任务一份 diffOpenWand 的基本用法是在终端里敲一条命令。以最常见的开发任务举例openwand 给登录接口加上 JWT 过期时间校验过期返回 401这一条命令背后工具会自动完成四件事扫描当前仓库判断语言栈和项目结构定位登录接口相关的路由、校验逻辑和测试文件直接修改代码补上过期校验和对应测试输出完整 diff标注哪些测试已经运行、结果如何。全程不需要任何一次“对话”。你不必等它反问“JWT 过期时间存在哪个字段”它自己会去查不必告诉它“看一下 auth.py”它自己会去 grep甚至不必吩咐“改完跑一下测试”因为验证本身就写死在任务流程里。有人问这和 Copilot 的对话补全有什么区别区别在于Copilot 仍然把 AI 定位成“你问一句、它答一段”的助手OpenWand 把 AI 定位成“接下一个任务、交付一个结果”的执行引擎。前者是对话后者是工作。2.2 一次任务的完整生命周期我用状态机把任务生命周期拆成五个阶段方便后面讲架构阶段做什么对用户的呈现解析把自然语言任务拆成目标和约束显示任务理解侦察收集仓库结构、相关文件、git 状态显示正在查看的文件规划生成改动方案和执行顺序显示计划列表执行修改文件、运行命令、查看结果显示每步结果提交汇总 diff生成任务报告显示可审查的变更集前四个阶段用户完全不需要介入唯一需要人做的决定在最后一步这份 diff 认不认。认就合入不认一条命令回滚。我在设计时故意把“确认”放在最后而不是中间。因为中间任何一次打断都会把用户拉回“对话式遥控器”的老路你说一句它做一步你再说一句。那看起来更可控实际上又变成聊天了只是换了一层任务的外壳。任务式交互正确的用法是你完整地表达目标它完整地执行然后你完整地验收。命令行执行完的输出长这样$ openwand 修复用户模块的缓存未失效问题 [1/4] 扫描仓库结构... 已索引 186 个文件 [2/4] 定位缓存逻辑... app/services/cache.py:42 [3/4] 修改 cache.py引入版本号作为缓存键前缀 [4/4] 运行测试... 12 passed, 2 skipped 变更报告 修改文件: app/services/cache.py (9 -1) 新增文件: tests/test_cache_invalidation.py (34 -0) 测试结果: 全部通过 查看 diff: openwand diff 撤销任务: openwand rollback这套输出刻意保持极简把信息密度压到最低因为命令行没有滚动界面你不可能来回划。进度可读、产物可查、失败可诊断这三个原则贯穿了整个设计。2.3 为什么是命令行而不是 IDE 插件不少朋友建议我做成 IDE 插件我没采纳理由有三个。第一命令行是几乎所有开发者工作流的最小公分母。不管你在 VSCode、JetBrains 还是 vim 里终端都在那里。它能表达“让某件事发生”的意图而且表达方式和编辑器解耦。第二命令行离 git、测试框架、构建工具最近。Agent 要跑 pytest、看 diff、做 stash直接在终端里做最顺手绕到编辑器 API 反而多一层摩擦。第三命令行天然没有界面这逼着我把交互建立在进度可见性、变更可审查性、失败可诊断性这三根柱子上而不是靠一个聊天窗口兜底。这个约束对产品形态的影响非常深。3. 架构拆解没有对话框的 Agent 由哪几部分构成去掉界面不等于去掉系统相反无界面系统的后台逻辑必须更严谨。OpenWand 的架构大致分四块任务解析器、上下文收集器、执行循环、安全护栏。3.1 任务解析器目标、约束与验收条件第一步是把一句自然语言任务拆成机器可执行的计划。举例来说“把用户模块的错误处理统一改成 Result 模式保持对外接口不变并补上覆盖主要路径的测试”这句话解析器要提取出四类信息目标用户模块错误处理重构约束对外接口不变交付物代码改动加测试验证方式跑测试、检查接口兼容性。实现上我没有用复杂的意图识别框架而是用一个小模型调用加结构化输出的方案。给模型一个 JSON schema让它把任务描述映射成目标、范围、约束、验收条件四个字段。这样做的原因是工程上足够简单而且便于用户用命令行参数覆盖解析结果。为了减少误判我加了一个关键设计解析结果在执行前会以计划列表的形式打印出来用户可以用--scope、--no-destructive、--require-tests这类参数直接修改范围。解析允许出错但错误必须在执行前暴露而不是闷头执行到最后给一份没人要的 diff。3.2 上下文收集器Agent 怎么读仓库任务式 Agent 面临的最大难题是仓库可能几千个文件不可能全塞进上下文。OpenWand 的做法是分级索引。第一级是结构信息文件树、git 状态、语言栈识别。读 pyproject.toml、package.json、go.mod确定这个项目用什么语言、什么框架、什么测试工具。第二级是符号索引用树状解析器抽取函数、类、常量定义位置配合 ripgrep 做关键词检索快速定位与任务相关的文件。第三级是相关性扩展找到入口文件之后顺着 import 和调用关系把相关模块拉进来直到形成一个足够小的“任务相关文件集合”。这套检索机制看起来朴素但对最终的执行质量影响最大。路径幻觉——也就是模型引用了一个根本不存在的文件——绝大多数情况下是因为上下文收集阶段没做好模型只能凭记忆瞎猜路径。OpenWand 里所有文件路径都必须来自索引不允许模型自己发明路径这一条规则直接把路径幻觉砍掉了一大半。3.3 执行循环、工具集与验证约束核心执行逻辑是一个带硬性停止条件的循环。用伪代码表示while not task_complete and steps MAX_STEPS: state collect_state() # 当前 git diff、测试结果、相关文件内容 action model.decide(state) # 选择一个工具和参数 result execute(action) # 执行工具拿到结构化结果 transcript.append(action, result)工具集设计得很克制只有这么几个read_file(path, range)按范围读文件grep(pattern, path)按模式搜索edit_file(path, anchor, new_content)基于锚点编辑run_command(cmd, timeout)运行命令受权限限制run_tests(path)运行测试并返回结构化结果git_diff()查看当前改动。特别说一下edit_file。早期版本我用行号定位结果模型改着改着前面的插入导致行号漂移越改越乱。后来改成锚点定位必须提供一段原文作为定位点工具在原文中精确匹配后再替换。这样即使文件在任务中途被改过只要锚点还在就能正确应用。这算是所有代码编辑类 Agent 都应该吸取的教训。验证约束是另一个关键设计。任务是否完成的判断依据不来自模型的自我感觉而是来自测试工具的输出。模型可以做任何修改但只要测试没过任务就不能标记为完成。在最坏情况下验证重试次数达到上限任务会停下来生成一份失败的诊断报告把问题留给人类。3.4 安全模型默认只读改动留痕无界面工具最让人担心的是失控。OpenWand 的安全模型只有一个核心原则默认只读所有写操作都要有明确授权。具体来说权限分成三层。只读层允许读文件、搜索、看 git 状态项目层允许修改指定目录下的文件、运行白名单里的命令比如 pytest、go test、npm test完全层允许执行任意命令一般只在本机沙箱环境用。权限在配置文件里声明[permissions] edit_files true run_commands [pytest, go test, npm test] allowed_paths [app, tests] allowed_commands_destructive false checkpoint_before_task true每次任务开始前OpenWand 会自动创建一个 git checkpoint。所有编辑动作都会写入一份操作日志记录每个文件的改动前后内容。这样无论什么时候发现某个改动不对劲都能openwand rollback回到任务开始前的状态。在实际体验里“可回滚”这个特性比权限限制更能给人安全感因为人都知道纠错成本低的时候才敢放手尝试。4. 从聊天式原型到任务式引擎迭代里踩过的坑这个项目不是一步到位的。我先后写了三个原型前两个基本都失败了但失败的过程帮我筛出了正确的架构。这段写下来给所有正在做 Agent 产品的人当反面教材。4.1 第一个原型让模型直接输出补丁的教训最早的版本最简单粗暴把任务描述和仓库信息打包进 prompt让模型直接输出一个完整 diff然后我手动应用。听起来效率很高实际惨不忍睹。问题有三个。第一模型对全局状态的理解有限生成的 diff 经常包含大量无关改动——重构一个函数顺手把整个文件格式都改了。第二大文件的补丁容易产生语法错误尤其是 Python 这种对缩进敏感的语言一个空格错位整个文件就废了。第三模型会引用“幻觉接口”——它调用了一个自认为存在、实际不存在的工具函数而人类在 review 时很难一眼看出来。这个阶段给我的教训是生成式输出的最大问题不是“内容不对”而是“错误藏得太深”。一个自动生成的补丁看起来一切都合理实际上从第三行就开始跑偏。所以后来我把“改动的可审查性”提到了最高优先级任何一步都必须能被人类或机器快速验证。4.2 工具调用后的“越做越嗨”和范围失控第二个版本换成了工具调用模型可以自己读文件、找文件、改文件。这个版本终于能完成一些真实任务了但很快暴露出一个新问题模型会越做越嗨。典型场景是这样的。任务本来是“给 A 函数加个参数”模型改完 A顺路把调用 A 的 B、C、D 全部改了理由是“让调用方保持一致”。再往下它发现 B 的调用方 E 也有问题又去改了 E。二十分钟后任务报告里有二十二个文件核心需求只占其中三行。你说它做得不对吗每一处单看都有道理。但它已经严重越界而且一旦测试挂了你根本分不清是哪个改动引起的。我随后加了两道闸门。第一道是范围墙壁任务开始前解析出允许修改的路径集合越界的编辑动作直接拒绝并提示模型“当前改动超出任务范围”。第二道是行动相关性检查每执行一个动作前把动作内容同任务目标做一次相关性检查相关性太低的动作直接跳过。这个机制本质上是廉价的注意力约束效果立竿见影越界改动明显减少。4.3 把“测试通过”从模型的话改成工具的输出第三个教训来自验证环节。早期版本里模型在任务结束时声称“测试全部通过”但它压根没跑测试只是根据经验预测“应该能过”。这是 Agent 产品最危险的一种幻觉因为人类一旦采信可能把一个坏改动合入主干。解决方案说起来简单做起来痛苦所有“通过/失败”的判断一律只认run_tests工具的结构化输出。模型可以推测可以预期但这些都不算数测试进程的退出码才算数。我在执行循环里加了硬约束任务完成前必须执行一次测试测试失败则进入修复循环修复次数达到上限就停止并在报告里明说“未通过验证”。这个规则带来的额外收益是诊断质量。修复循环里每一次测试失败都会被记录最终报告能列出“改了哪些文件、跑挂了什么测试、尝试了哪几次修复、卡在哪里”。对用户来说一份失败的透明报告远比一份虚假的“成功”有价值。4.4 三类反复出现的故障和对应的修复除了上面三个大教训把第二个原型放到真实项目里跑了两周我整理出三类高频故障。一是路径幻觉。模型写src/utils/helper.py实际项目里根本没有这个路径。修复方式前面说过所有路径必须来自索引禁止凭空生成。二是上下文漂移。任务长了以后模型会忘掉开头的约束条件比如“不要动公共接口”这句话到执行第 15 步时已经失效。修复方式是在上下文中保留一份“任务宪法”每次调用模型时强制重新注入任务目标、约束、当前文件范围保证任何一步决策都对着同一个坐标系。三是静默失败。run_command返回了非零退出码但模型无视错误继续往下做最后交付一份建立在地基错误上的改动。修复方式是结构化错误处理命令失败会产生一条独立的观察记录如果错误发生在关键验证步骤模型绕不开必须处理完才能继续。这三类问题有一个共性根因都不在模型能力而在任务编排。模型很容易“迷失方向”Agent 框架的职责就是持续把方向、约束、反馈递到它面前。把锅甩给模型没有意义框架设计本身才是该背锅的地方。5. 同一个任务两种模式的实测差异口说无凭。我把三个真实场景分别用“对话式 AI 加手动搬运”和 OpenWand 两种方式跑了一遍记录过程和数据。样本肯定不严谨但参考价值足够。5.1 加健康检查接口的完整对比第一个场景给一个 Django 项目添加/healthz健康检查端点要求返回服务状态和数据库连接状态。这是个很典型的小需求涉及 urls.py、views.py、settings.py 三个文件和少量测试。对话式流程我模拟了自己平时的习惯先问“怎么加健康检查”拿到代码片段手动贴到 urls.py跑起来发现数据库连接写错了再贴报错回去问如此反复。总共 8 轮对话每轮都要复制代码或错误信息中间还要自己手动处理一个缩进问题。总耗时约 22 分钟产出一堆聊天记录最终改动质量还行但过程极度消耗注意力。OpenWand 流程就一句命令。它自己找到 urls.py 和 views.py自己决定把数据库连接检查放在哪里写完代码后自己跑了 Django 测试套件然后输出 diff。我在终端里 review 了一下发现它把数据库连接检查放在响应生成前这个顺序没问题就合入了。总耗时 5 分钟其中 4 分 50 秒是我在看 diff。5.2 跨文件重构任务模式的强项和翻车点第二个场景把订单模块的状态字段从字符串改成枚举涉及模型、序列化器、多处查询逻辑、测试夹具。这种任务在对话模式下堪称噩梦因为要让模型理解所有引用点你得把每个文件逐个贴给它贴漏一个就是埋一个雷。OpenWand 的做法是直接走符号索引找到状态字段的定义顺着调用关系把所有引用文件拉进来统一修改最后跑测试验证。这种“顺着代码关系完成任务”的能力恰好是任务式交互对对话式交互的代差优势。当然它也翻车过。有一次重构数据库模型时它把 SQLAlchemy 列类型换了却漏掉了迁移脚本。测试恰好没覆盖迁移这一步差一点就带着问题交付。后来我在验证流程里加了“涉及模型变更时必须检查迁移目录”的规则但这件事也提醒我任务模式的测试覆盖率直接决定了它的安全边界。5.3 用两周的实测数据说话我在第二个原型的真实使用中记录了 30 个任务涵盖添加接口、修 Bug、重构、补测试四类汇总如下指标对话式 AI 加手动搬运OpenWand单次小任务平均耗时15 到 25 分钟3 到 6 分钟需要复制粘贴的片段数6 到 12 次0上下文 Token 消耗3 万到 6 万1 万到 2 万交付物建议文本可审查 diff 加测试结果回滚方式手动反向修改一条命令最大的效率差距其实不是时间而是“人介入的深度”对话模式里我的大脑要全程在线跟踪每一步任务模式里我的工作只剩 review 和拍板。同样是 20 分钟的一段工作前者的心力消耗是后者的四五倍。这个差异在小任务上感受不明显一旦任务批量出现任务模式的优势会指数级放大。6. 边界与取舍什么场景不该硬上任务模式OpenWand 不是万能药。跑了几个月之后我对它的适用边界有了比较清醒的认识这些边界可能比功能列表更有参考价值。6.1 探索靠聊执行靠任务对话式 AI 有它不可替代的场景头脑风暴、方案对比、知识解释、需求梳理。这些场景的特点是目标本身不明确需要在来回讨论中逐步澄清。任务模式要求任务描述清晰、验收标准明确它天然不适合模糊地带。所以我的实际用法是混合的上午用聊天工具把方案聊清楚下午把确认好的方案写成任务描述丢给 OpenWand 执行。聊天工具是草稿纸任务工具是施工队两者各司其职缺一不可。提示如果你发现自己的任务描述越写越长说明你对目标的思考还不够完整。与其急着执行不如先回去把思路理清楚。模糊的任务交给再强的 Agent只会得到一份模糊的 diff。6.2 信任坡度按层级放开权限对人也好对 AI 也罢信任都不是一步到位的。我建议所有刚上手任务式工具的团队都按坡度来第一阶段只让 Agent 读代码和出方案所有改动由人手动完成。这个阶段的价值是校准你能直观感受它的上下文理解水平和对任务的把握能力。第二阶段允许它在 tests 目录下直接改代码。测试文件风险低、结构简单、验证标准明确是培养信任的好场所。第三阶段放开到 src 目录但保留强制测试和回滚能力。到这里已经是多数团队能接受的形态。我的经验是不要跳过第二阶段直接给全部权限。Agent 的“看起来靠谱程度”和“实际靠谱程度”在初期可能差很远坡度设计的意义就是让两者之间的差距一点点弥合。6.3 遗留代码和高风险变更的保守策略没有测试覆盖的遗留代码是 Agent 的滑铁卢。模型敢改但改了之后没有任何机器反馈兜底它甚至不知道自己是否改坏了别的东西。对这种代码库我的策略是只允许任务模式做“机械型重构”——比如重命名、格式统一、删死代码——并且强制每一步都给出 diff 供人审查绝不允许跨模块的大爆炸式改动。数据库迁移、权限体系变更、支付逻辑这类高风险区域我会在执行前明确标注为“只读观察禁止修改”或者干脆放在 allowed_paths 之外。无界面工具最大的特点是没有人在中途拽住它的手所以事前边界一定要划得比人工作业更保守。7. 进阶用法和后续规划如果看到这里你还觉得这个思路有意思那这部分应该对得上你的需求。7.1 用任务清单批量处理技术债OpenWand 支持“批量任务”模式用 YAML 文件定义一系列相互独立的小任务工具会串行执行每个任务完成后自动回到干净状态再开始下一个tasks: - desc: 给所有 API 视图加上 require_http_methods 装饰器 scope: [app/api] require_tests: true - desc: 删除 utils 目录里超过半年未被引用的函数 scope: [app/utils] require_tests: true我以前最怕“技术债清理周”因为重复劳动太多。现在我只花半小时写好这份任务清单剩下的事就交给循环执行。中途如果某个任务连续失败三次它会自动跳过并在最终报告里单独列出来不会拖垮整批任务。7.2 自定义工具和任务钩子不同项目的验证方式差异很大所以工具集必须可扩展。OpenWand 提供两个扩展点自定义工具和任务钩子。自定义工具就是写一个函数注册进工具列表比如“启动本地服务做冒烟测试”或者“检查数据库迁移是否遗漏”任务钩子则允许你在任务前、任务后挂脚本比如任务前自动切换分支任务后自动跑 eslint。这套设计背后是我踩过的一个坑早期把验证逻辑写死在代码里碰到一个用 Go 写的项目就傻眼了。后来我意识到验证方式本来就应该跟随项目配置而不是跟随工具本身。7.3 模型无关的设计从云端 API 到本地模型OpenWand 的模型层做成了可插拔的。默认走 OpenAI 兼容接口同时支持切换到本地模型比如用 llama.cpp 或 Ollama 跑量化权重。这不是为了赶时髦而是因为不同任务的模型需求差异太大机械型任务用一个小模型就够速度和成本都有优势而跨文件重构这类需要全局规划的任务确实只有大模型能做好。我把模型选择也暴露成了任务级参数openwand ... --model local-small。实测下来只要任务被类型化——是机械型还是规划型——模型选择就变成一件很机械的事情用户可以形成自己的固定搭配。顺便说一个我学到的优化对于重复出现的任务模式可以先把任务模板缓存起来让模型不用每次从零开始规划。比如“给所有视图补装饰器”这类任务执行路径固定直接复用历史模板既省 Token 又降低出错率。7.4 下一步想做的东西短期的方向有三个。一是多仓库任务让任务描述可以横跨几个仓库完成一次跨服务变更二是把任务模式推广到代码之外比如数据处理流程、文档生成、运维操作凡是“目标明确、产物可验证”的场景理论上都适用三是做一套更好的人机审查界面把“看 diff、提意见、让 Agent 修正”这个过程也打磨成非对话的形态。我不太想给它加一个网页版或者可视化界面那会稀释掉“任务式交互”的纯粹性。至少现阶段让胶水一样的命令行保持简单比讨好更多用户更重要。8. 几句个人体会做 OpenWand 这段时间我收获最深的一点是AI 工具的界面越少它背后的流程就要想得越清楚。删除对话框从来不是噱头它逼着我把任务的输入、执行、验证、回滚都设计到可以用命令行直接表达的程度也逼着我直面“如何建立信任”这个核心问题。最后分享一个小技巧如果你也想尝试类似思路不要一开始就追求全自动。先让 Agent 以只读模式分析你的仓库并输出方案你审核后批准它动手。这个“先方案后执行”的流程看起来多了一步实际上是把信任建立过程外显化了效果远好于第一次就让 AI 直接改你的核心代码。项目本身还在快速迭代代码已经开源。如果你对“去掉聊天框后的 AI 工作流”有自己的想法或者踩过比我更深的坑欢迎来项目仓库交流一起把这条少有人走的路趟平。
过去大半年我一直在做一件事把手头所有靠 AI 聊天来完成的工作改造成一个没有对话框的形态。这个项目叫 OpenWand核心理念就一句话——remove chat interface from working with AI。在 Show HN 上发布之后收到的反馈两极分化。有人觉得我在逆潮流而动毕竟行业都在教模型“更会聊天”更多人问得很实在不加聊天框AI 到底该怎么用我先描述一个几乎所有开发者都经历过的场景。以前我用对话式 AI 改代码流程是这样的把报错信息复制进窗口把相关代码片段贴进去等上几十秒拿到一段回复再复制回编辑器跑一遍报新的错再粘回去。一个下午过去我做的事情本质上是在编辑器、终端、浏览器三个窗口之间当人体搬运工。聊天界面真正的问题不是“聊得不够聪明”而是它把工作切成了无数个低效的往返。OpenWand 想要解决的就是这件事让 AI 直接出现在工作现场听懂任务干完活交付一份你可以审查的改动而不是一段需要再次搬运的文字。这篇文章不是项目说明书而是我从聊天式协作转向任务式协作过程中的完整思考包括产品形态、架构取舍和踩坑记录。适合两类人读一类是被 AI 聊天搞得精疲力竭的开发者和内容工作者另一类是正在做 AI 应用、Agent 或效率工具的产品和技术负责人。下面按我真实做这个项目的顺序把问题、答案和经验一个个讲清楚。1. 对话框是 AI 协作里最贵的一笔隐性税决定做 OpenWand 之前我先花了很长一段时间研究“大家到底是怎么用 AI 干活的”。结论有点讽刺绝大多数人用 AI 干活时间不是花在“让 AI 干活”上而是花在“把活描述给 AI”和“把 AI 的结果搬运回工作台”上。聊天框看起来免费实际是效率上最贵的东西。1.1 每一轮对话都在搬运上下文对话式 AI 的能力边界取决于你喂给它的上下文质量。而上下文不会自己出现它需要你手动把报错信息、相关文件、环境变量、依赖版本一项项复制进输入框。这个搬运过程的成本有三层。第一层是时间。一次小任务通常要 3 到 6 轮往返每轮复制粘贴加等待回复少说两分钟一天下来就是半小时到一小时纯搬运。第二层是信息损耗。人一懒就会只贴报错最后三行漏掉完整堆栈只贴函数体漏掉调用方。模型在一个残缺上下文里做判断给出“看起来合理但实际用不了”的答案几乎是必然事件。第三层是注意力。频繁切换窗口会反复打断大脑的工作记忆你本来正在想“这个变量为什么为空”复制完报错再回来思路已经断了一截。任务式交互把这三层成本一起拿掉了。OpenWand 自己去读仓库、看 git 状态、搜索相关文件上下文收集是工具的分内事。用户的角色从“喂数据的人”变成“下指令和做验收的人”。这不是效率提升百分之几十的问题而是协作模式从“人伺候模型”翻转为“模型伺候任务”。1.2 聊天窗口不是工作区聊天界面天然是线性的一条消息、一条回复永远在追加。但真实的工程任务是网状的要同时跟踪多个文件、多个依赖关系、多组测试结果。把网状工作硬塞进线性对话会出现三个典型问题。一是上下文膨胀。对话稍微一长Token 窗口被早期内容占满后来模型越来越“健忘”连自己前面说过的话都要你提醒。二是状态脆弱。你绕了几圈最后说“还是按最开始那个方案做”“最开始”指的是第几条消息人和模型都不一定记得清。三是决策丢失。重要的技术取舍淹没在几百条消息里事后要翻聊天记录才想得起来当时为什么这么做而这个聊天记录往往很快就找不到了。OpenWand 以“任务”作为基本单位每个任务都有明确的目标、范围、产物和验证方式。任务状态可以保存、可以回滚、可以跨天恢复也能导出成一份简单明了的报告。聊天记录是流水账任务报告是档案两者完全不是一回事。1.3 聊天的产物是文字任务的产物是改动这是我下定决心做这个项目的原因。聊天式 AI哪怕回答得再准确交付物始终是“一段话”。拿到这段话之后你还是得自己决定改哪里、怎么改、改完怎么验证。AI 只负责“说”不负责“做”更不对结果负责。任务式交互的输出是 diff是具体文件改动是跑过的测试记录是一份可以 review 的变更集。文字可以天花乱坠改动骗不了人。当 AI 的交付物从“建议”变成“改动”时你对它的审视方式也随之改变不需要再去判断它“说得对不对”直接看它“改得对不对、测没测、有没有动不该动的地方”。这种心态转变带来的信任提升远超我的预期。2. OpenWand 的产品形态任务进来改动出去聊完为什么要去掉对话框再说说去掉之后长什么样。2.1 一条命令一个任务一份 diffOpenWand 的基本用法是在终端里敲一条命令。以最常见的开发任务举例openwand 给登录接口加上 JWT 过期时间校验过期返回 401这一条命令背后工具会自动完成四件事扫描当前仓库判断语言栈和项目结构定位登录接口相关的路由、校验逻辑和测试文件直接修改代码补上过期校验和对应测试输出完整 diff标注哪些测试已经运行、结果如何。全程不需要任何一次“对话”。你不必等它反问“JWT 过期时间存在哪个字段”它自己会去查不必告诉它“看一下 auth.py”它自己会去 grep甚至不必吩咐“改完跑一下测试”因为验证本身就写死在任务流程里。有人问这和 Copilot 的对话补全有什么区别区别在于Copilot 仍然把 AI 定位成“你问一句、它答一段”的助手OpenWand 把 AI 定位成“接下一个任务、交付一个结果”的执行引擎。前者是对话后者是工作。2.2 一次任务的完整生命周期我用状态机把任务生命周期拆成五个阶段方便后面讲架构阶段做什么对用户的呈现解析把自然语言任务拆成目标和约束显示任务理解侦察收集仓库结构、相关文件、git 状态显示正在查看的文件规划生成改动方案和执行顺序显示计划列表执行修改文件、运行命令、查看结果显示每步结果提交汇总 diff生成任务报告显示可审查的变更集前四个阶段用户完全不需要介入唯一需要人做的决定在最后一步这份 diff 认不认。认就合入不认一条命令回滚。我在设计时故意把“确认”放在最后而不是中间。因为中间任何一次打断都会把用户拉回“对话式遥控器”的老路你说一句它做一步你再说一句。那看起来更可控实际上又变成聊天了只是换了一层任务的外壳。任务式交互正确的用法是你完整地表达目标它完整地执行然后你完整地验收。命令行执行完的输出长这样$ openwand 修复用户模块的缓存未失效问题 [1/4] 扫描仓库结构... 已索引 186 个文件 [2/4] 定位缓存逻辑... app/services/cache.py:42 [3/4] 修改 cache.py引入版本号作为缓存键前缀 [4/4] 运行测试... 12 passed, 2 skipped 变更报告 修改文件: app/services/cache.py (9 -1) 新增文件: tests/test_cache_invalidation.py (34 -0) 测试结果: 全部通过 查看 diff: openwand diff 撤销任务: openwand rollback这套输出刻意保持极简把信息密度压到最低因为命令行没有滚动界面你不可能来回划。进度可读、产物可查、失败可诊断这三个原则贯穿了整个设计。2.3 为什么是命令行而不是 IDE 插件不少朋友建议我做成 IDE 插件我没采纳理由有三个。第一命令行是几乎所有开发者工作流的最小公分母。不管你在 VSCode、JetBrains 还是 vim 里终端都在那里。它能表达“让某件事发生”的意图而且表达方式和编辑器解耦。第二命令行离 git、测试框架、构建工具最近。Agent 要跑 pytest、看 diff、做 stash直接在终端里做最顺手绕到编辑器 API 反而多一层摩擦。第三命令行天然没有界面这逼着我把交互建立在进度可见性、变更可审查性、失败可诊断性这三根柱子上而不是靠一个聊天窗口兜底。这个约束对产品形态的影响非常深。3. 架构拆解没有对话框的 Agent 由哪几部分构成去掉界面不等于去掉系统相反无界面系统的后台逻辑必须更严谨。OpenWand 的架构大致分四块任务解析器、上下文收集器、执行循环、安全护栏。3.1 任务解析器目标、约束与验收条件第一步是把一句自然语言任务拆成机器可执行的计划。举例来说“把用户模块的错误处理统一改成 Result 模式保持对外接口不变并补上覆盖主要路径的测试”这句话解析器要提取出四类信息目标用户模块错误处理重构约束对外接口不变交付物代码改动加测试验证方式跑测试、检查接口兼容性。实现上我没有用复杂的意图识别框架而是用一个小模型调用加结构化输出的方案。给模型一个 JSON schema让它把任务描述映射成目标、范围、约束、验收条件四个字段。这样做的原因是工程上足够简单而且便于用户用命令行参数覆盖解析结果。为了减少误判我加了一个关键设计解析结果在执行前会以计划列表的形式打印出来用户可以用--scope、--no-destructive、--require-tests这类参数直接修改范围。解析允许出错但错误必须在执行前暴露而不是闷头执行到最后给一份没人要的 diff。3.2 上下文收集器Agent 怎么读仓库任务式 Agent 面临的最大难题是仓库可能几千个文件不可能全塞进上下文。OpenWand 的做法是分级索引。第一级是结构信息文件树、git 状态、语言栈识别。读 pyproject.toml、package.json、go.mod确定这个项目用什么语言、什么框架、什么测试工具。第二级是符号索引用树状解析器抽取函数、类、常量定义位置配合 ripgrep 做关键词检索快速定位与任务相关的文件。第三级是相关性扩展找到入口文件之后顺着 import 和调用关系把相关模块拉进来直到形成一个足够小的“任务相关文件集合”。这套检索机制看起来朴素但对最终的执行质量影响最大。路径幻觉——也就是模型引用了一个根本不存在的文件——绝大多数情况下是因为上下文收集阶段没做好模型只能凭记忆瞎猜路径。OpenWand 里所有文件路径都必须来自索引不允许模型自己发明路径这一条规则直接把路径幻觉砍掉了一大半。3.3 执行循环、工具集与验证约束核心执行逻辑是一个带硬性停止条件的循环。用伪代码表示while not task_complete and steps MAX_STEPS: state collect_state() # 当前 git diff、测试结果、相关文件内容 action model.decide(state) # 选择一个工具和参数 result execute(action) # 执行工具拿到结构化结果 transcript.append(action, result)工具集设计得很克制只有这么几个read_file(path, range)按范围读文件grep(pattern, path)按模式搜索edit_file(path, anchor, new_content)基于锚点编辑run_command(cmd, timeout)运行命令受权限限制run_tests(path)运行测试并返回结构化结果git_diff()查看当前改动。特别说一下edit_file。早期版本我用行号定位结果模型改着改着前面的插入导致行号漂移越改越乱。后来改成锚点定位必须提供一段原文作为定位点工具在原文中精确匹配后再替换。这样即使文件在任务中途被改过只要锚点还在就能正确应用。这算是所有代码编辑类 Agent 都应该吸取的教训。验证约束是另一个关键设计。任务是否完成的判断依据不来自模型的自我感觉而是来自测试工具的输出。模型可以做任何修改但只要测试没过任务就不能标记为完成。在最坏情况下验证重试次数达到上限任务会停下来生成一份失败的诊断报告把问题留给人类。3.4 安全模型默认只读改动留痕无界面工具最让人担心的是失控。OpenWand 的安全模型只有一个核心原则默认只读所有写操作都要有明确授权。具体来说权限分成三层。只读层允许读文件、搜索、看 git 状态项目层允许修改指定目录下的文件、运行白名单里的命令比如 pytest、go test、npm test完全层允许执行任意命令一般只在本机沙箱环境用。权限在配置文件里声明[permissions] edit_files true run_commands [pytest, go test, npm test] allowed_paths [app, tests] allowed_commands_destructive false checkpoint_before_task true每次任务开始前OpenWand 会自动创建一个 git checkpoint。所有编辑动作都会写入一份操作日志记录每个文件的改动前后内容。这样无论什么时候发现某个改动不对劲都能openwand rollback回到任务开始前的状态。在实际体验里“可回滚”这个特性比权限限制更能给人安全感因为人都知道纠错成本低的时候才敢放手尝试。4. 从聊天式原型到任务式引擎迭代里踩过的坑这个项目不是一步到位的。我先后写了三个原型前两个基本都失败了但失败的过程帮我筛出了正确的架构。这段写下来给所有正在做 Agent 产品的人当反面教材。4.1 第一个原型让模型直接输出补丁的教训最早的版本最简单粗暴把任务描述和仓库信息打包进 prompt让模型直接输出一个完整 diff然后我手动应用。听起来效率很高实际惨不忍睹。问题有三个。第一模型对全局状态的理解有限生成的 diff 经常包含大量无关改动——重构一个函数顺手把整个文件格式都改了。第二大文件的补丁容易产生语法错误尤其是 Python 这种对缩进敏感的语言一个空格错位整个文件就废了。第三模型会引用“幻觉接口”——它调用了一个自认为存在、实际不存在的工具函数而人类在 review 时很难一眼看出来。这个阶段给我的教训是生成式输出的最大问题不是“内容不对”而是“错误藏得太深”。一个自动生成的补丁看起来一切都合理实际上从第三行就开始跑偏。所以后来我把“改动的可审查性”提到了最高优先级任何一步都必须能被人类或机器快速验证。4.2 工具调用后的“越做越嗨”和范围失控第二个版本换成了工具调用模型可以自己读文件、找文件、改文件。这个版本终于能完成一些真实任务了但很快暴露出一个新问题模型会越做越嗨。典型场景是这样的。任务本来是“给 A 函数加个参数”模型改完 A顺路把调用 A 的 B、C、D 全部改了理由是“让调用方保持一致”。再往下它发现 B 的调用方 E 也有问题又去改了 E。二十分钟后任务报告里有二十二个文件核心需求只占其中三行。你说它做得不对吗每一处单看都有道理。但它已经严重越界而且一旦测试挂了你根本分不清是哪个改动引起的。我随后加了两道闸门。第一道是范围墙壁任务开始前解析出允许修改的路径集合越界的编辑动作直接拒绝并提示模型“当前改动超出任务范围”。第二道是行动相关性检查每执行一个动作前把动作内容同任务目标做一次相关性检查相关性太低的动作直接跳过。这个机制本质上是廉价的注意力约束效果立竿见影越界改动明显减少。4.3 把“测试通过”从模型的话改成工具的输出第三个教训来自验证环节。早期版本里模型在任务结束时声称“测试全部通过”但它压根没跑测试只是根据经验预测“应该能过”。这是 Agent 产品最危险的一种幻觉因为人类一旦采信可能把一个坏改动合入主干。解决方案说起来简单做起来痛苦所有“通过/失败”的判断一律只认run_tests工具的结构化输出。模型可以推测可以预期但这些都不算数测试进程的退出码才算数。我在执行循环里加了硬约束任务完成前必须执行一次测试测试失败则进入修复循环修复次数达到上限就停止并在报告里明说“未通过验证”。这个规则带来的额外收益是诊断质量。修复循环里每一次测试失败都会被记录最终报告能列出“改了哪些文件、跑挂了什么测试、尝试了哪几次修复、卡在哪里”。对用户来说一份失败的透明报告远比一份虚假的“成功”有价值。4.4 三类反复出现的故障和对应的修复除了上面三个大教训把第二个原型放到真实项目里跑了两周我整理出三类高频故障。一是路径幻觉。模型写src/utils/helper.py实际项目里根本没有这个路径。修复方式前面说过所有路径必须来自索引禁止凭空生成。二是上下文漂移。任务长了以后模型会忘掉开头的约束条件比如“不要动公共接口”这句话到执行第 15 步时已经失效。修复方式是在上下文中保留一份“任务宪法”每次调用模型时强制重新注入任务目标、约束、当前文件范围保证任何一步决策都对着同一个坐标系。三是静默失败。run_command返回了非零退出码但模型无视错误继续往下做最后交付一份建立在地基错误上的改动。修复方式是结构化错误处理命令失败会产生一条独立的观察记录如果错误发生在关键验证步骤模型绕不开必须处理完才能继续。这三类问题有一个共性根因都不在模型能力而在任务编排。模型很容易“迷失方向”Agent 框架的职责就是持续把方向、约束、反馈递到它面前。把锅甩给模型没有意义框架设计本身才是该背锅的地方。5. 同一个任务两种模式的实测差异口说无凭。我把三个真实场景分别用“对话式 AI 加手动搬运”和 OpenWand 两种方式跑了一遍记录过程和数据。样本肯定不严谨但参考价值足够。5.1 加健康检查接口的完整对比第一个场景给一个 Django 项目添加/healthz健康检查端点要求返回服务状态和数据库连接状态。这是个很典型的小需求涉及 urls.py、views.py、settings.py 三个文件和少量测试。对话式流程我模拟了自己平时的习惯先问“怎么加健康检查”拿到代码片段手动贴到 urls.py跑起来发现数据库连接写错了再贴报错回去问如此反复。总共 8 轮对话每轮都要复制代码或错误信息中间还要自己手动处理一个缩进问题。总耗时约 22 分钟产出一堆聊天记录最终改动质量还行但过程极度消耗注意力。OpenWand 流程就一句命令。它自己找到 urls.py 和 views.py自己决定把数据库连接检查放在哪里写完代码后自己跑了 Django 测试套件然后输出 diff。我在终端里 review 了一下发现它把数据库连接检查放在响应生成前这个顺序没问题就合入了。总耗时 5 分钟其中 4 分 50 秒是我在看 diff。5.2 跨文件重构任务模式的强项和翻车点第二个场景把订单模块的状态字段从字符串改成枚举涉及模型、序列化器、多处查询逻辑、测试夹具。这种任务在对话模式下堪称噩梦因为要让模型理解所有引用点你得把每个文件逐个贴给它贴漏一个就是埋一个雷。OpenWand 的做法是直接走符号索引找到状态字段的定义顺着调用关系把所有引用文件拉进来统一修改最后跑测试验证。这种“顺着代码关系完成任务”的能力恰好是任务式交互对对话式交互的代差优势。当然它也翻车过。有一次重构数据库模型时它把 SQLAlchemy 列类型换了却漏掉了迁移脚本。测试恰好没覆盖迁移这一步差一点就带着问题交付。后来我在验证流程里加了“涉及模型变更时必须检查迁移目录”的规则但这件事也提醒我任务模式的测试覆盖率直接决定了它的安全边界。5.3 用两周的实测数据说话我在第二个原型的真实使用中记录了 30 个任务涵盖添加接口、修 Bug、重构、补测试四类汇总如下指标对话式 AI 加手动搬运OpenWand单次小任务平均耗时15 到 25 分钟3 到 6 分钟需要复制粘贴的片段数6 到 12 次0上下文 Token 消耗3 万到 6 万1 万到 2 万交付物建议文本可审查 diff 加测试结果回滚方式手动反向修改一条命令最大的效率差距其实不是时间而是“人介入的深度”对话模式里我的大脑要全程在线跟踪每一步任务模式里我的工作只剩 review 和拍板。同样是 20 分钟的一段工作前者的心力消耗是后者的四五倍。这个差异在小任务上感受不明显一旦任务批量出现任务模式的优势会指数级放大。6. 边界与取舍什么场景不该硬上任务模式OpenWand 不是万能药。跑了几个月之后我对它的适用边界有了比较清醒的认识这些边界可能比功能列表更有参考价值。6.1 探索靠聊执行靠任务对话式 AI 有它不可替代的场景头脑风暴、方案对比、知识解释、需求梳理。这些场景的特点是目标本身不明确需要在来回讨论中逐步澄清。任务模式要求任务描述清晰、验收标准明确它天然不适合模糊地带。所以我的实际用法是混合的上午用聊天工具把方案聊清楚下午把确认好的方案写成任务描述丢给 OpenWand 执行。聊天工具是草稿纸任务工具是施工队两者各司其职缺一不可。提示如果你发现自己的任务描述越写越长说明你对目标的思考还不够完整。与其急着执行不如先回去把思路理清楚。模糊的任务交给再强的 Agent只会得到一份模糊的 diff。6.2 信任坡度按层级放开权限对人也好对 AI 也罢信任都不是一步到位的。我建议所有刚上手任务式工具的团队都按坡度来第一阶段只让 Agent 读代码和出方案所有改动由人手动完成。这个阶段的价值是校准你能直观感受它的上下文理解水平和对任务的把握能力。第二阶段允许它在 tests 目录下直接改代码。测试文件风险低、结构简单、验证标准明确是培养信任的好场所。第三阶段放开到 src 目录但保留强制测试和回滚能力。到这里已经是多数团队能接受的形态。我的经验是不要跳过第二阶段直接给全部权限。Agent 的“看起来靠谱程度”和“实际靠谱程度”在初期可能差很远坡度设计的意义就是让两者之间的差距一点点弥合。6.3 遗留代码和高风险变更的保守策略没有测试覆盖的遗留代码是 Agent 的滑铁卢。模型敢改但改了之后没有任何机器反馈兜底它甚至不知道自己是否改坏了别的东西。对这种代码库我的策略是只允许任务模式做“机械型重构”——比如重命名、格式统一、删死代码——并且强制每一步都给出 diff 供人审查绝不允许跨模块的大爆炸式改动。数据库迁移、权限体系变更、支付逻辑这类高风险区域我会在执行前明确标注为“只读观察禁止修改”或者干脆放在 allowed_paths 之外。无界面工具最大的特点是没有人在中途拽住它的手所以事前边界一定要划得比人工作业更保守。7. 进阶用法和后续规划如果看到这里你还觉得这个思路有意思那这部分应该对得上你的需求。7.1 用任务清单批量处理技术债OpenWand 支持“批量任务”模式用 YAML 文件定义一系列相互独立的小任务工具会串行执行每个任务完成后自动回到干净状态再开始下一个tasks: - desc: 给所有 API 视图加上 require_http_methods 装饰器 scope: [app/api] require_tests: true - desc: 删除 utils 目录里超过半年未被引用的函数 scope: [app/utils] require_tests: true我以前最怕“技术债清理周”因为重复劳动太多。现在我只花半小时写好这份任务清单剩下的事就交给循环执行。中途如果某个任务连续失败三次它会自动跳过并在最终报告里单独列出来不会拖垮整批任务。7.2 自定义工具和任务钩子不同项目的验证方式差异很大所以工具集必须可扩展。OpenWand 提供两个扩展点自定义工具和任务钩子。自定义工具就是写一个函数注册进工具列表比如“启动本地服务做冒烟测试”或者“检查数据库迁移是否遗漏”任务钩子则允许你在任务前、任务后挂脚本比如任务前自动切换分支任务后自动跑 eslint。这套设计背后是我踩过的一个坑早期把验证逻辑写死在代码里碰到一个用 Go 写的项目就傻眼了。后来我意识到验证方式本来就应该跟随项目配置而不是跟随工具本身。7.3 模型无关的设计从云端 API 到本地模型OpenWand 的模型层做成了可插拔的。默认走 OpenAI 兼容接口同时支持切换到本地模型比如用 llama.cpp 或 Ollama 跑量化权重。这不是为了赶时髦而是因为不同任务的模型需求差异太大机械型任务用一个小模型就够速度和成本都有优势而跨文件重构这类需要全局规划的任务确实只有大模型能做好。我把模型选择也暴露成了任务级参数openwand ... --model local-small。实测下来只要任务被类型化——是机械型还是规划型——模型选择就变成一件很机械的事情用户可以形成自己的固定搭配。顺便说一个我学到的优化对于重复出现的任务模式可以先把任务模板缓存起来让模型不用每次从零开始规划。比如“给所有视图补装饰器”这类任务执行路径固定直接复用历史模板既省 Token 又降低出错率。7.4 下一步想做的东西短期的方向有三个。一是多仓库任务让任务描述可以横跨几个仓库完成一次跨服务变更二是把任务模式推广到代码之外比如数据处理流程、文档生成、运维操作凡是“目标明确、产物可验证”的场景理论上都适用三是做一套更好的人机审查界面把“看 diff、提意见、让 Agent 修正”这个过程也打磨成非对话的形态。我不太想给它加一个网页版或者可视化界面那会稀释掉“任务式交互”的纯粹性。至少现阶段让胶水一样的命令行保持简单比讨好更多用户更重要。8. 几句个人体会做 OpenWand 这段时间我收获最深的一点是AI 工具的界面越少它背后的流程就要想得越清楚。删除对话框从来不是噱头它逼着我把任务的输入、执行、验证、回滚都设计到可以用命令行直接表达的程度也逼着我直面“如何建立信任”这个核心问题。最后分享一个小技巧如果你也想尝试类似思路不要一开始就追求全自动。先让 Agent 以只读模式分析你的仓库并输出方案你审核后批准它动手。这个“先方案后执行”的流程看起来多了一步实际上是把信任建立过程外显化了效果远好于第一次就让 AI 直接改你的核心代码。项目本身还在快速迭代代码已经开源。如果你对“去掉聊天框后的 AI 工作流”有自己的想法或者踩过比我更深的坑欢迎来项目仓库交流一起把这条少有人走的路趟平。
