<Github图片有点难传>
首先，运行程序：go run ./tui/main.go
首次使用程序会要求用户自己配置环境变量AI_API_KEY
配置好后可能需要用户手动重启程序（这个不太好，还是得考虑环境变量放哪 .env）
然后，用户告知neo-code ：
”帮我创建一个golang的四则运算器“
问题/使用如下
AI 收到请求，首先list当前目录
这里流式输出，aI未主动中断，无法检测流式输出完毕
</think>块处理不当
AI思考后返回 ** json格式 **
{
"tool": "工具名称（如list/read/bash）",
"params": {"参数名": "参数值"},
"thought": "你调用该工具的原因"
}
调用本地工具
系统打印工具日志并自动成为下一步的对话message直接发送给ai (调试阶段，命令反馈到用户应该只需要执行成功与否)
流式模型需要更加严格的Json审查
ai审查目录后发送write工具指令调用write
调用工具结果作为系统消息发送回ai决定下一步行动
初步达成在用户端创建文件和感知环境（prompt和工作区感知有待加强）
相比起上一版内容
有了较为美观的bubble tea做前端
有了最基本的对话循环和工具调用能力
对apikey做了基本防护（算吗？）
能够返回流式输出的对话流刷新TUI
有人设，不再是chatbot ，能够自我调用工具处理问题
下一个方向在—>添加ctx上下文 赋予工作区感知能力
<Github图片有点难传>
首先，运行程序：go run ./tui/main.go
首次使用程序会要求用户自己配置环境变量AI_API_KEY
配置好后可能需要用户手动重启程序（这个不太好，还是得考虑环境变量放哪 .env）
然后，用户告知neo-code ：
”帮我创建一个golang的四则运算器“
问题/使用如下
AI 收到请求，首先list当前目录
</think>块处理不当AI思考后返回 ** json格式 **
{
"tool": "工具名称（如list/read/bash）",
"params": {"参数名": "参数值"},
"thought": "你调用该工具的原因"
}
调用本地工具
系统打印工具日志并自动成为下一步的对话message直接发送给ai (调试阶段，命令反馈到用户应该只需要执行成功与否)
流式模型需要更加严格的Json审查
ai审查目录后发送write工具指令调用write
调用工具结果作为系统消息发送回ai决定下一步行动
初步达成在用户端创建文件和感知环境（prompt和工作区感知有待加强）
相比起上一版内容
有了较为美观的bubble tea做前端
有了最基本的对话循环和工具调用能力
对apikey做了基本防护（算吗？）
能够返回流式输出的对话流刷新TUI
有人设，不再是chatbot ，能够自我调用工具处理问题
下一个方向在—>添加ctx上下文 赋予工作区感知能力