我最近可能和大家反着来了。 当很多人在追求更自动化的软件生产流水线时，我反而开始慢下来，做更多和 Agent 结对编程的事情。 当越来越多的人把思考、技术设计也交给 AI 时，我却在一点点把这些权限收回来。 现在更多时候，我自己负责思考和做技术设计，AI 用来帮我搜集信息、探索未知、解答问题，以及做一些可行性分析和前期调研。 等我的方案基本成形之后，再让它基于我的设计补齐细节、检查遗漏，最后由我确认。 这样做下来，效果特别好，而且真的很爽。 在具体、局部的问题上，AI 确实很强，也懂得很多。但一旦把问题放进完整的产品交互、业务逻辑和系统上下文里，它很难给出一个让我特别满意的方案。 这时候，人自己的经验、判断和对产品的理解就很有价值。 比如今天早上送娃上学的路上，我突然想到一个办法，可以让产品里的一个功能点体验明显更好。 这种东西往往来自你长期对产品的理解，以及脑子里持续不断地琢磨。 如果只是把需求丢给 AI，让它自己设计，它大概率想不到。

我应该不会让自己的孩子太早接触和依赖 AI。 AI 用得越久，我越觉得，它终究只是一个生产力工具。它可以帮我们提高效率，让工作变得更轻松、更方便，但一个人真正重要的能力，比如独立思考、提出问题、保持好奇心和创造力，这些能力很难直接从 AI 身上获得。 尤其是在孩子成长的阶段，我更希望她们把时间花在读书、画画、写东西、运动、做手工、探索真实世界，以及和不同的人交流上。 这些事情看起来没有 AI 那么高效，却恰恰是在慢慢建立一个人的感受力、判断力、想象力和思考能力。 AI 很擅长帮人省力，很多原本需要自己搜索、思考、组织和尝试的事情，现在问一句就能得到答案。成年人用久了都很容易产生依赖，更何况孩子。 还有一个是现在的 AI 太像一个“懂很多东西的人”了。它说话非常自然，语气也常常十分肯定，很容易让人产生信任感。但它依然可能理解错误、给出错误答案，甚至把错误内容讲得头头是道。 成年人尚且需要不断提醒自己去验证和质疑，孩子就更难分辨了。如果从小习惯直接询问 AI，然后接受它给出的答案，种习惯影响批判性思维的形成。 教育从来都不只是把知识告诉孩子，而是让她们自己去探索去思考。孩子会不会理解偏、有没有产生错误认知、什么时候需要鼓励、什么时候需要纠正，这些都需要成年人观察和判断。 相比于早早玩 AI，我更希望她们先学会自己观察、自己思考、自己提问，逐渐建立起独立判断的能力。 等具备这些基础之后，再去使用 AI，它才更可能成为一个真正有用的工具，而且也很容易学习。

这个帖子非常神奇，29k views, 300+likes, 50+ comments 中竟然没有那些垃圾搞黄色的评论，只有个别几个蓝 V AI 评论。 评论区有不少有价值的建议，感兴趣的朋友可以翻翻看看。

说真的, @mattpocockuk 的 grill-me，应该是我使用频率最高，同时也觉得最有用的 Skill 之一。 我在做产品和技术设计时，经常会用它来帮我检查，还有哪些地方没有真正想清楚。 很多时候，大的交互框架、产品流程和技术方向其实已经比较明确了，但往下落到细节，就会发现还有很多模糊的地方。有些是自己遗漏了，有些是之前压根没有想到，还有一些更常见的情况是，AI 已经给出了方案，甚至做出了 Mock UI，我看完却总觉得不太对。 麻烦就在这里。 我知道自己不满意，却又很难立刻说清楚，到底哪里有问题，以及我真正想要的是什么。 这时候我通常会先把目前的想法、目标和已有方案告诉 Agent，然后直接来一句：grill me。 接下来，Agent 就会开始不断盘问我。 它会沿着设计中的一个个分支继续往下问，把那些原本模糊的地方一点点挖出来：这个功能到底解决什么问题？这个状态应该怎么处理？用户为什么要在这里做这个动作？两种方案之间你真正看重的是什么？ 很多问题，我其实从来没有认真想过。 而在一轮轮回答这些问题的过程中，原本只是脑子里一个模糊的感觉，会逐渐变成非常具体的产品决策。 这也是我觉得 grill-me 最有价值的地方。 有时候你缺的并不是 AI 再给你一个方案，而是有人不断追问，帮你把自己真正想要的东西想明白。

如果你也在考虑精简自己的 AGENTS.md，很推荐读一下 @mattpocockuk 的这篇文章，里面还附了一个可以直接让 Agent 帮你重构 AGENTS.md 的 Prompt： 看完以后，我觉得其中有几个观点特别值得分享。 1. 尽量不要用 /init 自动生成 AGENTS.md 这一点是我过去没有意识到的。 自动生成往往会追求“全面”，把项目结构、命令、技术栈、代码路径、实现方式等大量信息都塞进去。 其中很多内容 Agent 本来就可以自己从代码和配置文件中发现，还有一些会随着项目演进很快过时。 一旦这些过期信息长期存在于 AGENTS.md 里，每次任务都会进入上下文，反而可能干扰 Agent 的判断。 2. 不要重复 Agent 可以轻易发现的信息，也尽量避免维护容易过时的实现细节 比如具体代码在哪个目录、某个模块目前位于哪个文件、某项功能当前由哪个 Service 实现。 代码一直在变化，这类信息很容易失效。 更值得写进去的，是一些稳定、重要，同时又很难单纯从代码里推断出来的信息： 项目目标、关键约束、特殊工具链，以及几乎所有任务都应该遵守的原则。 那些 Agent 可以通过搜索代码找到的信息，就让它在真正需要时再去探索。 3. 一个很重要的原则是 Progressive Disclosure，也就是渐进式披露 不要试图把所有规则都塞进根目录的 AGENTS.md。 测试规范、TypeScript 约定、API 设计、数据库规则、Git Workflow 等，都可以拆到独立文档或 Skills 中。 根目录的 AGENTS.md 更适合做一个很薄的“入口”和“路由器”： 做什么事情时，应该去哪里读取对应的规则和上下文。 这样 Agent 只有在真正需要的时候才会加载那部分内容，可以减少上下文噪音，也能降低不同指令互相干扰的概率。 Monorepo 还可以进一步使用不同目录下的 AGENTS.md，让规则跟着作用域走。 -------- 这篇文章也让我重新理解了 AGENTS.md 的定位。 以前很容易把它当成一份“尽可能完整的项目说明书”，什么都想往里面加。 现在我更倾向于把它看成： Agent 每次开始工作时都会读取的一组高优先级上下文。 既然它会影响几乎每一次任务，那么每增加一条内容，都值得问一句： 这条信息真的值得在每一次任务里占用 Agent 的注意力吗？ 如果答案是否定的，就可以考虑把它交给代码本身、独立文档、Skills、Hooks，或者其他按需加载的机制。 所以，AGENTS.md 值得认真写，也值得定期删。 精简它的意义也不只是节省 Token。 更重要的是管理 Agent 的注意力，以及有限的 Instruction Budget。 很多时候，少一点，Agent 反而工作得更好。

herdr 这几天好像很火，我前天下载尝试了下就没用了，回到了我自己配置的 tmux 方案更舒服，主要是它的界面不如我自己定制的灵活。 但我今天频繁刷到它，甚至连 tibo 和 dhh 都推荐了，大佬们都推荐了说明它一定是哪里特别好用？

看完海明的分享，最大的感受是：独立开发这条路，真的比想象中难，但也比想象中更有可能。 两年前离开公司时，我其实也经历过类似的迷茫。 第一年主要做外包，赚了一些钱；第二年开始尝试做自媒体、做独立 App。过程中有过很多怀疑，也无数次想过是不是应该重新找工作。 因为独立开发最难的地方，从来不是写代码。 真正困难的是，你需要一个人完成产品定位、用户调研、设计、开发、营销、增长和商业化。 任何一个环节没有做好，都会非常吃力。 所以海明能够两年做到这个成绩，我觉得非常难得。 这背后不仅是开发能力，更重要的是完成了一套从产品到收入的完整闭环。 我自己的 App 目前还远远达不到这个水平。上线 5 个月左右，目前收入 4000+ 美金。如果单纯看收入，其实和上班相比性价比并不高，投入的时间和精力也非常大。 但作为一个独立开发者，我对这个阶段的结果已经很满意。 现在回头看，海明提到的几个经验确实非常重要： 做好市场验证，认真设计 Onboarding 和付费墙，持续输出内容，在各种渠道推广自己的产品。 很多开发者以为产品做好了就结束了。 但实际上，做出来只是开始，让用户发现它，并愿意付费，才是真正的挑战。 现在这个时代，对于独立开发者来说确实是一个很好的窗口。 AI 降低了开发成本，自媒体降低了传播成本，全球市场也提供了更多可能。 希望自己也能继续熬过增长阶段，走到下一步。

ChatGPT 移动端和桌面端目前还是设备配对的逻辑，为什么登录同一个账户不可以无缝连接，还要配对？ 比如说我的 iPhone 可以操作 Mac mini 了，但想要连接我的 Macbook 就要配对。 现在我拿着我的 Android 手机，想要继续工作，又要配对才行。 这设计不太合理。

实际跑一跑 codex 定时任务才发现，原来定时任务运行时环境和我们在对话中的执行环境是不一致的，执行时电脑中原本所存在的一些命令都不见了。 为了解决这个问题，先是在 `~/.codex/config.toml` 中增加以下内容: [shell_environment_policy] inherit = "all" experimental_use_profile = true 然后新建`~/.zprofile`，重新设置 export PATH，才能够正常加载。 这个意思是启用 profile 继承，让 Codex 通过用户配置的 shell 获取环境。

每天都有一些琐碎的固定小任务，每个花不了几分钟，但积少成多就很分散注意力，挺累的。 一直想自动化，但搞自动化本身又要花不止几分钟，就总是算了。 拖久了，今天终于受不了，花时间用 Codex Schedule 把这些事一个个做成定时循环任务，让它自己跑，有问题再通知我。省下的时间其实没有很夸张，但注意力释放了，脑子轻松很多。

发现一篇不错的英文文章，随时导入到 SentiaRead 中继续阅读，查词并加入生词本，翻译和解释，不要太方便。 摩擦力低了，才愿意读更多。

这个 App 最开始是自己用的，是走的 LLM 方案，先整体翻译，然后按句子配对，再 LLM 拆分，但是拆分效果总是不理想。 另外走 LLM 还有一个问题，就是要配置 API Key，这其实对普通人不友好，另外就是成本其实不低，Gemini 3.5 Flash 一部长一点视频都几美元。 最后发现还是 Agent + Skill 路线最好： 1. Agent 有很好的纠错能力，哪怕你不给它这样的工具，它自己都能一边翻译一边纠错，质量不错。 2. 把 App 的能力封装成 cli，让 Agent 可以通过命令行调用 App 的功能 3. 配合一个 Skill 把常用的工作流比如像转录、润色、翻译、对齐、剪辑都固化下来，这样 Agent 就知道最佳实践是什么，不需要每次都自己摸索 4. App 解决的是人工预览、校对的部分。 Agent 操作完，如果你是人肉看文本字幕，或者你每次修改一点都要重新 ffmpeg 生成一遍视频，那效率太低了。最好的方式其实不是完全交给 Agent，而是可以有一个图形化的工具快速的预览、二次编辑。 5. Agent 相对比较通用和便宜，现在大家都有 Agent，包月的 Token 经常花不完，用来干这种活正合适

Manus 最初是云端 Agent 形态，可搭配手机使用，体验非常丝滑。 OpenClaw 把风吹到了本地 Agent，大家纷纷做桌面端或增强桌面端的能力。 最近我隐约感受到云端 Agent 会成为未来的主流，云端一体化的协作才更舒服，单纯依赖于本地化的环境有诸多不便，任务并发也不方便。

GPT 命名太乱了，给人带来的心智负担太大，因此我现在只使用 GPT-Sol, 根据任务复杂度切换 Effort，且不使用 fast，交给它的多数是执行任务、Debug 和修 Bug，再或者是本身就是设计好的开发任务，慢点就慢点吧。需要结对编程、讨论以及快速修改迭代的就在 claude code 和 cursor 中完成了。