咱们一天的精力，多半花在了关注圈——抱怨老板、骂大环境、替别人的人生操心。柯维在《高效能人士的七个习惯》里留了一张特别朴素的图：影响圈和关注圈。同样的劲，花在影响圈里过几个月就有回声，花在关注圈里只剩内伤。这是一篇关于"力气往哪儿使"的复盘。

一边用 AI 一边刷信息流，我把自己刷得越来越浅，直到重读《思考，快与慢》才意识到——AI 时代真正稀缺的不是答案，是肯慢下来想一件事的能力。这是一篇关于"装了又卸"的自我反省，也是一份给工程师的"反系统 1"操作清单。

拆 gstack 这个 Claude Code 脚手架——它把 sprint 拆成了 30+ 个 slash command，工程上有真功夫，方法论上更值得抄；但工具栏拥堵和文档膨胀，也是 AI 时代项目的通病。这篇讲哪些值得偷师，哪些要警惕，以及自己做类似项目时怎么避坑。

传统 Build Pipeline 是为"人写代码、机器构建"设计的；AI 编程时代需要一条新流水线——SDD（OpenSpec + DDD）→ TDD → BDD → MDD，配上静态分析、AI Review、规则检查，把"AI 生成"变成"AI 可交付"。

一个好的 AI Skill 不只是提示词，而是一套可触发、可分流、可执行、可验证的工作流。本文以 Anthropic 的 PDF skill 为例，拆解它的设计亮点，也指出它在 PDF-to-Markdown 解析上的关键缺口。

PARA Method 把任务、资料和想法分成 Project、Area、Resource、Archive 四类。它的好处不在于多几个文件夹，而在于少一点分类犹豫，让项目、责任区、资料和归档各归其位。本文基于 Todoist 对 PARA 的介绍，整理一套今天就能上手的步骤、判断表和避坑清单。

这两年装了一堆 AI Todo App，可清单越列越长，人却越管越乱。事务管理真正的升级，不在工具，而在把任务从"人脑里的提醒"变成"AI 能读懂的工件"，再让 AI 反过来主动驱动你。本文梳理 GTD、四象限、PARA、OKR 在 AI 时代怎么演进，给出 GTD + AI 的五步闭环和"AI 主动驱动"的进阶模式，以及个人和工作事务分别该怎么落地。

从 Markdown、AsciiDoc、reStructuredText、LaTeX、Typst 到结构化 JSON，纯文本生成 docx/pdf 看起来只是格式转换，真正麻烦的是源格式选型、样式契约、版式一致性、Web 在线编辑、安全沙箱和多人协作。

Vibe Coding 可以把编码速度拉满，但开发者不能把判断力也交出去。真正值得练的能力，是从逐行写代码升级为制定规则、绘制蓝图、技术把关和产品监控。

AI 生成内容越来越快，真正的问题不是产能不足，而是人类判断成了瓶颈。解决办法不是让人加班改稿，而是给 AI 内容生产搭一套质量闸门，让人把精力放在方向、判断和定稿上。

Codex 真正的生产力，不在于写一条神奇 Prompt，而在于把 AGENTS.md、rules、hooks、memories、skills 和 worktrees 组合成一套可重复、可验证、可演进的工程环境。

Martin Fowler 的《Harness engineering for coding agent users》提醒我们，想让 coding agent 少添乱、多干活，光靠更大的模型还不够，还要把模型外面的规则、工具、反馈和验证系统搭起来。AI 工程化正在从 prompt 技巧，走向 harness engineering。

这两年"AI"几乎成了 LLM 的代名词，一聊 AI 就是 ChatGPT、Claude、提示词工程，仿佛 AI 就等于聊天机器人。作为一个在多个领域做过工程落地的老工程师，我想说：这个认知框架太窄了——AI 是一个庞大的技术生态，LLM 只是其中一个（虽然眼下最耀眼的）分支。

"一人公司"（OPC）这两年成了中年程序员的精神图腾——自由、自主、不再被裁。但朋友圈里晒 OPC 的多，活过两年的少。本文不灌鸡汤，也不贩卖焦虑，只把这条路上的坑、限制和缝隙讲清楚：为什么国内 ToC 和 ToB 都难走、哪几条路可能跑通、辞职前应该先过哪张自检清单。

过去几年，Meta、Google、Microsoft、Amazon 等软件和 IT 大公司的裁员消息，把很多程序员的职业安全感打碎了。作为一个写了二十多年代码的老程序员，本文不卖焦虑也不灌鸡汤，只把这团心事拆开看：你怕的到底是什么、AI 拿不走的能力是哪些、像我这样的"全栈老兵"还有没有用武之地，以及怎么用 SWOT、技能矩阵和三圈模型给自己做一次职场体检。

LLM API 的成本控制不是少用 AI，而是把 token 当工程资源来管。先度量，再分级选模型，压缩上下文，复用缓存，限制输出，离线任务走批处理，最后拿检查清单管住那些看不见的浪费。

零停机服务不是一句“部署两套集群”就能实现的口号。真正可用的方案，是 active-active 流量、快速超时、跨集群重试、熔断摘除、共享幂等状态和无状态应用设计一起配合，让一次集群故障尽量止步于一次请求内部。

RAG 看起来不过是"先检索，再生成"，真正做起来才知道坑不少。分块、检索、重排序、Prompt、引用、评估，任何一环偷懒，最后都可能变成一个很自信的胡说八道机器。

产线故障发生时，真正让团队稳下来的不是某个高手突然开天眼，而是一套提前准备好的结构：Runbook 负责行动，时间线负责事实，决策树负责判断，检查表负责防漏。四件武器配合得好，故障处理就从“群里互相喊话”变成“按步骤止血、按证据决策、按事实复盘”。

AI 把写代码的门槛拉低了，把判断代码好坏的门槛拉高了。经验不会自动变成优势，反而容易变成包袱。咱们要做的，是用 DDD 守住业务语言，用 ROI 算清楚账，再用品味在多个可行方案里挑那个"长期最少后悔"的。