@mrkiddoe 你说的有道理，也值得考虑。

便捷性值得对比考虑。不过对我来说，使用一个独立 App ，需要另外一个安装，而且它是否和 Agent 对话是否紧密结合是不确定的。截图之后，可能需要手动添加文件，每个 Agent 的交互可能都不一样。对我来说 / 之后，马上进入截图模式，效率上应该是更高的。

LLM 调用之外，我理解应该会使用的，不过我个人的频率会非常低，我个人基本有问题只找 AI 解决。不过，有需要的话，可能还是需要安装的，一般办公软件可能也提供类似的，我理解这是两种需求，就像你说的用可以用截图软件解决 AI 对话的问题，我倒是觉得他们有不同的适合场景。

你说的 appshots 我得去了解一下。

@mrkiddoe 不是的，我写了一个 SKILL ，做截屏用的。Codex 支持这个功能吗？ 我用 Cursor 没看到。

AI 的时代，学习方法已经完全变了，Codex / Claude 就是你最好的工具。 先去尝试实践，然后发现问题，让 AI 解答。

@WilliamColton 其实技术能力区别不大，但这是一种更高效的面向 AI 的协作形态，快速调取截图，快速读取内容。传统的截图软件是独立的软件，AI 的时代工具都要成为 LLM 的 Tools 。所以，你开发的工具，都必须 AI 友好的，而不是割裂的。所以，很多软件都在提供 MCP 能力，软件的能力要被 LLM 调用到，否则要被淘汰。

欢迎对 研发工作流 有自己思考和沉淀的朋友讨论、共创！

不好意思各位，刚刚看到回复。 附加一个介绍说明，详情可以看 lulu-workflow.html 架构介绍。


我开源了自己每天在用的 AI 开发工作流：lulu-workflow

用 AI 写代码，我踩过最大的坑不是模型不够强，而是需求没想清楚就开始写。结果是返工、跑偏，一个会话里的上下文还会越写越乱。

所以我把流程拆成了两条线：

想清楚产品和架构：brainstorm → bet → blueprint → approach → arch
把功能做到代码：brainstorm → bet → spec → approach → design → plan → tasks → code → review
几个我自己比较在意的设计：

每个阶段有明确产物：decision → spec → tech decision → design → plan ，上一步没定，下一步不开工。
用 Hook 做硬约束：写入控制、强制注入、执行提醒，不靠"提示词求 AI 听话"。
会话可恢复：多 Cycle 隔离，跨会话继续。
有评测环节：探测、评估、修复，而不只是"写完了"。
还有一个我越用越确信的判断：AI 的思考不等于人的理解，所以要先充分发散，再收敛。

仓库： https://github.com/lulufoo/lulu-workflow 架构图： https://lulufoo.github.io/interview/lulu-workflow.html

想听听大家的看法：

你现在是怎么避免 AI "没想清楚就开写"的？
这套阶段拆分你觉得哪里太重或多余？
觉得有用的话欢迎点个 Star ，更欢迎提 Issue 吵架。

目前 Board 的协议是我设计的；正准备支持 Mermaid 画板编辑，不过还在开发完善中。