CodeCaster

我觉得干活还是得开 Full Access ，不然效率太低，总被打断不可取，但是 OP 的问题也是需要防的，我的做法就是用自己开发的工具，所有小的拆的开发任务都是进入独立的沙箱（ docker 容器）的，这样，沙箱中他只能看到自己的一个分支的工作目录，就算发生了故障，也没有关系。

@qwei 深入使用之后，你可以用里面的命令自动开沙箱，自动创建 git worktree 后隔离，不绑定某一个 TUI

https://github.com/fitlab-ai/agent-infra ，我自己一直在沉淀工作中的工作流，的确需要按照软件工程的方法来一点一点迭代演进：
1. 先发现问题，然后通过自然语言和 AI Agent 交流定义清楚问题，然后用 skill ，/create-task ，创建一个任务
2. 接下来就是分析循环（/analyze-task 和 /review-analysis ）
3. 接下来是设计循环（/plan-task 和 /review-task ）
4. 最后是编码循环（/code-task 和 /review-code ）
5. 上面的 3 个循环在不同 TUI 交接过程中，他们会自己解决发现的问题，如果有些他们判断不应该自由发挥，就上升到人类决策，就提示我来看，然后我就分析下自然语言和他们说了继续
6. 全部搞定，就 /commit -> /create-pr -> /complete-task

OP ，我已经做了一个工具了，把你说的每一步都标准化了，且每一步输出都是一个文档，可以开不同的窗口切不同的 Agent 来继续，且命令行操作很方便，你可以试试，我自己一直用了 4 个多月了。如果 OP 觉得好用，可以帮忙点一个 star 。链接：
https://github.com/fitlab-ai/agent-infra

没有办法注册呀，日常都挂梯子的，你的网站注册不了

我个人觉得，给外部的大模型了，数据别人一定是知道的，就算分片，也保不准某个机密的点不泄露。但看你的项目的保密程度，绝对不允许外泄的，那就私有化部署好了，其他的，现在生成代码的成本这么低了，说实话，没有人关心那些代码。
但如果你真要分不同模型搞，但有担心上下文，我现在的工作模式到时可以给你参考一下：
1. 第一点原则，绝对不让一个大模型来搞，一定是让多加大模型一起搞的，就像我们人类团队一样，不同的人（ Agent ）有不同的想法，让差异化来来确保尽可能不出系统风险
2. 基于这个原则，那就把任务拆小之后，确保每一步的上下文足够（文本化），然后让不同编程工具一步一步的接手处理就好了
3. 我基于这个想法，就做了一套 skill ，把每个阶段的工作全部封装成一个 skill ，同时可以在不同的 TUI 中运行（相当于任何一个 Agent 都能接手工作，Claude 、Codex 、gemini 、opencode 等），然后就开源了，现在我个人的所有开发工作全部基于这套 SOP 来搞
4. 项目地址： https://github.com/fitlab-ai/agent-infra
5. 你看看是不是可以用于你的场景方法？是的话，可以尝试下，好用的话，就点个 star 好了

我自己最近把自己的开发模式沉淀成了一套 skill ，然后分别在不同 TUI 里面封装 slash command ，项目都是标准流程开发，要切换也很方便，你可以试试呢？
项目地址： https://github.com/fitlab-ai/agent-infra

我最近自己总结了近一年使用各种 TUI 的经验后，写了一套 Skill ，基本半自动化在开发了，可以看看，地址： https://github.com/fitlab-ai/agent-infra

想问一下，这个项目的名字是什么意思呢？