从一句话，到可以检查的结果
写代码、查资料、处理文件、制作内容，看起来是不同任务，却经常遇到同一个问题：回答已经有了，事情还没有做完。Lime 的起点，是让智能体进入实际工作环境，把对话推进成能够检查和修改的结果。
任务的终点应该看得见
“帮我看看这个项目”可以开始一次对话，却很难判断何时结束。换成“复现这个报错，做最小修复，运行现有测试，并说明没有验证的部分”，目标就有了可检查的形状。报告、代码差异、整理后的文件，都可以成为这样的终点。
我们用“能把事情做完”描述方向，也把完成标准留给具体任务。模型的判断、工具的访问范围和环境条件都会影响结果。好的交付应当同时说明做了什么、依据是什么，以及哪些地方还需要确认。
让上下文靠近正在做的工作
真实工作通常已经有一个起点：仓库、资料目录、旧稿、错误日志，或者一份待处理的表格。把这些材料放进项目，比在每次对话里重新解释背景更容易保持一致。你可以告诉 Lime 哪些文件是事实源，哪些只是参考，哪些目录不应修改。
桌面端提供可查看项目、会话和产出的工作空间；CLI/TUI 适合在终端中延续代码与文件任务。选择入口时，先考虑你需要查看什么、操作什么，以及怎样审阅结果。
工具把建议连接到产出
读取文件、修改代码、运行命令、查看网页，是把建议变成结果的具体动作。需要额外能力时，可以按任务配置模型服务、MCP 工具和 Skills。能力是否可用，取决于当前客户端、服务与工具配置，不能只靠一段提示词获得。
过程也需要可见。命令失败、来源打不开、依赖缺失，都应当成为任务中的明确状态。保留这些信息，下一轮才能从实际进度继续，而不是反复生成一份看似完整的新答案。
检查之后，再继续下一步
收到结果时，先看差异或文件，再看验证记录。代码任务要检查触发路径；研究任务要抽查来源；内容任务要核对事实和素材要求。把修改意见指向具体位置，让下一轮工作有明确依据。
你可以从一个小任务开始：修一个能复现的问题，整理一组资料，或者把一份简报变成草稿。先走通目标、执行与检查这条路径，再把稳定步骤沉淀为自己的工作方式。