Daily Productivity Sharing修改

2026-01-26 22:31:01

One helpful tip per day:)

Kieran Klaassen 说，在 AI 出现之前，代码审查意味着要逐行阅读同事写下的每一行代码；而现在，我的代码审查已经不再需要阅读代码本身了；而且正因为如此，我反而更擅长发现问题。

1. 这是一种“复利工程（compound engineering）”式的代码审查：多个智能体并行审查，发现的问题被转化为决策，而每一次修正都会教会系统下次该重点检查什么。
2. 放弃人工逐行审查时，我曾担心自己会失去那种清晰感，架构会在我不知情的情况下逐渐偏离。
3. 当开发者写了 200 行代码时，他们的经理可能需要花 20 到 40 分钟来阅读；写代码与审查代码的时间比例通常维持在 5:1 或 10:1。
4. AI 打破了这个比例。 生成代码所需的时间被极度压缩，但人类审查代码所需的时间却没有同步缩短——于是，必然有东西要让步。
5. 为什么需要这么多智能体？因为无论是人还是 AI，单一审查者都不可能在一次涉及 27 个文件的改动中捕捉到所有问题。
6. 安全专家能发现认证漏洞，却可能忽略数据库问题；性能专家能抓住慢查询，却会放过风格漂移。
7. 我需要的是并行工作的专家，每个都专注于自己擅长的领域；它们合在一起，能捕捉到我在人工审查中可能遗漏的东西。
8. 智能体（Agents） 是高度专业化的 AI 工作者：每一个都在独立的 Markdown 文件中定义，拥有明确的人设和关注重点。

如果你喜欢的话，不妨直接订阅这份电子报 ⬇️

2026-01-23 08:00:30

One helpful tip per day:)

Dan Koe 说，你之所以还没到达你想去的地方，是因为你还不是那个本该在那里的人。

1. 当我妈妈告诉我应该休息一下、出去玩、找点乐子时……我会忍住不说：“如果我不觉得好玩，我为什么要做我正在做的事？”
2. 如果你想在生活中获得某个具体结果，那么在抵达之前很久，你就必须先拥有能够产出这个结果的生活方式。
3. 当你真正改变了自己，所有那些无法推动你目标前进的习惯都会变得令人作呕，因为你对这些行为最终会复利成怎样的人生，有着深刻而清醒的认知。
4. 你之所以能接受自己当前的标准，是因为你并没有真正意识到这些标准是什么，或者它们最终会把你带到哪里。
5. 你说你想改变，你说你想“实现财务自由”“变得健康”，但你的行为却并非如此——这是有原因的。
6. 理解心智的第一步，是认识到：所有行为都是目标导向的。
7. 事实上，你始终是在试图达成某个目标；在这种情况下，这个目标也许是：保护自己免于因完成并公开作品而遭受的评判。
8. 真相是，你在追求的是安全感、可预测性，以及一个不让自己在那些把“干着没前途的工作”视为成功标志的人面前显得失败的借口。
9. 这里的教训是：真正的改变，来自于改变你的目标。
10. 目标是一种对未来的投射，它像一副认知透镜，让你更容易注意到那些有助于你达成目标的信息、想法和资源。
11. 当你的身体感到受威胁时，会进入“战或逃”的状态；当你的身份认同感到受威胁时，情况也是一样。
12. 成功是有公式的：
    • 一个要素是能动性（agency）；
    • 一个要素是机会（opportunity）（很多人把它误认为“特权”，是因为他们忽略了其他要素）；
    • 最后一个要素是智力（intelligence）。
13. 高智力意味着能够反复迭代、持续坚持，并理解整体格局；低智力的标志，是无法从错误中学习。
14. 高智力还意味着意识到：在足够长的时间尺度下，任何问题都可以被解决；现实是，你可以实现任何你真正下定决心的目标。
15. 智力在于明白：确实存在一系列选择，它们会一步步把你带到你想要的目标。
16. 我们这个流程的目标，是帮助你抵达“失调点”，穿越不确定性，真正发现你到底想实现什么——清晰到令人无法忽视，分心不再有重量。
17. 早上，你进行一次心理“挖掘”，揭示自己隐藏的动机；白天，通过自我提醒让自己跳出自动驾驶状态，反思人生；晚上，把这些洞见综合成一个你明天就会开始行动的方向。
18. 留出 15–30 分钟（也就是一条 YouTube 视频的时间——你做得到）来思考并回答这些问题；不要试图把这种思考外包给 AI。
19. 这些问题是为了让你意识到当前生活中的痛苦；接下来，我们要把它们转化为我所说的“反愿景（anti-vision）”——对你不想要的人生形成一种残酷而清醒的认知。
20. 如果你诚实地回答了这些问题，而且你正处在人生的合适阶段，你会对自己现在的生活产生一种深层的不安，甚至是厌恶；接下来，我们要把这股能量引导到积极的方向。
21. 与其把目标看成一个终点，不如把它当作一种视角：一副你可以随时切换的透镜，让你进入正确的心智状态，去采取那些能把你带离不想要人生的行动。
22. 你的愿景，是你获胜的方式——至少在游戏规则再次进化之前。
23. 你的一年目标，是你的主线任务（mission）；这是你人生中唯一的优先级。
24. 你的一月项目，是你的Boss 战；你在这里获得经验值（XP）和战利品。
25. 你的每日杠杆，是你的支线任务（quests）；这是每天解锁新机会的过程。
26. 你的约束条件，是规则；正是这些限制，催生了创造力。

如果你喜欢的话，不妨直接订阅这份电子报 ⬇️

2026-01-22 08:00:31

One helpful tip per day:)

Addy Osmani 认为：AI 提高了代码产量，把负担转移到了人类身上：

1. 到 2026 年初，超过 30% 的资深开发者表示，他们交付的代码主要由 AI 生成。
2. 当你是独立开发者，或是在一个需要他人长期维护你代码的团队中工作时，工作流与心态会截然不同。
3. 能以高速度成功使用 AI 的开发者，并不是盲目信任它的人，而是那些构建了验证系统、能在问题进入生产环境前捕获错误的人。
4. 对独立开发者而言，真正的改变来自与语言无关、数据驱动的测试。 如果测试足够全面，智能体就能用任何语言构建（或修复）实现，并在过程中持续验证。
5. 即便在高速推进中，也要一看到丑陋的代码就修，不要让混乱不断堆积。
6. 当多名工程师协作时，错误的成本和代码的长期可维护性就成为更大的关注点。
7. 当产出增长速度超过验证能力时，代码审查就会成为系统的瓶颈。
8. AI 扩大了攻击面，因此混合式方法更优：AI 先标记问题，人类再做验证。
9. 如果代码涉及认证、支付、密钥或不可信输入，就把 AI 当作一个高速实习生：在合并前必须进行人工威胁建模审查，并跑一遍安全工具。
10. 当开发者提交自己并未完全理解的 AI 生成代码时，他们就破坏了团队韧性所依赖的知识传递机制。
11. AI 可以向你倾倒大量代码，但团队必须控制产出规模，避免审查被淹没。
12. 提示 AI 智能体在生成代码后执行代码或运行单元测试；要求给出证据：日志、截图、结果。
13. 将 AI 的审查输出视为建议性意见——一种对话：一个 AI 写代码，另一个 AI 做审查，人类来统筹修复。把 AI 审查当作拼写检查，而不是总编辑。
14. AI 负责筛选容易的问题；人类负责解决困难的问题。
15. 强制渐进式开发。 把工作拆成小块——更利于 AI 生成，也更便于人类审查。带有清晰说明的小提交可作为检查点。
16. 人类审查者的角色更像编辑或架构师：专注于真正重要的部分，把琐碎检查交给自动化。
17. 无论技术如何进步，核心原则不变：代码审查确保软件满足需求，并且安全、健壮、可维护。
18. AI 时代最优秀的代码审查者，会拥抱这种转变——让 AI 加速机械性工作，同时牢牢把住问责关。
19. 拥抱 AI，但永远不要忘记：一定要再次核查成果。

如果你喜欢的话，不妨直接订阅这份电子报 ⬇️

2026-01-21 08:00:12

One helpful tip per day:)

Scott Young 认为：制定一个时间表很容易；但真正坚持执行——尤其当工作在认知上要求很高时——却异常困难：

1. 依我观察，高效的管理者并不是从任务开始，而是从时间开始；他们也不是一上来就做规划，而是先弄清楚自己的时间实际上都花在了哪里。
2. 相反，我们中的大多数更像是我邮箱里的学生：我们想要管理时间，但真正坚持按计划执行，远比把计划写出来要难得多。
3. 当我们听到“生产力”这个词时，脑海里往往首先浮现的是：要再努力一点、再拼一点。
4. 但事实上，当我们处在最高效的状态时，工作往往带着一种轻盈感。
5. 当你管理好的是精力而不是时间，工作就不会显得那么吃力，甚至可以是愉悦的。
6. 若生产力建议要真正有用，它应该是一张路线图，告诉你如何让工作更像那些令人愉快的项目，而更少像令人疲惫的苦差。
7. 如果做这件事很轻松，你会选择做什么？ 这个理想在所有情况下未必完全可达，但至少能让我们看清：我们想要实现的事情，与我们自觉拥有的精力之间，究竟差了多远。

如果你喜欢的话，不妨直接订阅这份电子报 ⬇️

2026-01-20 08:00:06

One helpful tip per day:)

Cursor 团队分享了如何使用 Cursor 的最佳实践，其中不少也适用于其他工具：

1. 一个智能体“执行框架（agent harness）”由三部分组成：
   1. 指令（Instructions）：用于引导智能体行为的系统提示与规则
   2. 工具（Tools）：文件编辑、代码库搜索、终端执行等能力
   3. 用户消息（User messages）：你的提示与追问，用于推动工作
2. 这个框架之所以重要，是因为不同模型对同一套提示的反应会不一样。
3. 你能做的最有影响力的改变，是先规划，再编码。
4. 规划会迫使你更清晰地思考要构建什么，并为智能体提供可努力达成的具体目标。
5. 点击 “Save to workspace”，把计划保存到 .cursor/plans/。这会为团队生成文档，便于从中断处继续，也为未来在同一功能上工作的智能体提供上下文。
6. 并非每个任务都需要详细计划；对快速改动或你已经重复做过很多次的任务，直接交给智能体也完全可以。
7. 如果结果不理想，就回滚改动，把计划写得更具体、更贴近你真正想要的内容，然后再跑一遍；这往往比在一个跑偏的智能体过程中修修补补更快，也会产出更干净的结果。
8. Cursor 的智能体有强大的搜索能力，会按需拉取上下文；当你问“认证流程”时，它会通过 grep 和语义搜索找到相关文件，即使你的提示里并没有出现完全相同的词。
9. 保持简单：如果你知道具体文件，就直接标注；如果不知道，智能体会自己找到。塞进不相关的文件反而会让智能体误判重点。
10. 在以下情况开始新对话：
    • 你要切换到另一个任务或功能
    • 智能体看起来迷糊，或反复犯同样的错误
    • 你已经完成了一个逻辑工作单元
11. 经过很多轮对话与摘要后，上下文会累积噪音，智能体可能被分散注意力或跑到无关任务上；如果你感觉它的效果在下降，就该开新对话了。
12. 开新对话时，用 @Past Chats 引用之前的工作，而不是把整段对话复制粘贴过来；智能体可以有选择地读取历史，只拉取它需要的上下文。
13. Cursor 提供两种主要方式来定制智能体行为：用于静态上下文的 Rules（适用于每次对话），以及提供动态能力的 Skills（在相关时启用）。
14. Rules 提供持久化指令，塑造智能体与你的代码交互的方式；可以把它理解为“始终开启的上下文”，每次对话开始时智能体都会看到。
15. 从简单开始：只在你发现智能体反复犯同一种错误时才添加规则；在还没理解自己的模式之前，不要过度优化。
16. 当你看到智能体犯错时，就更新规则；你甚至可以在 GitHub issue 或 PR 里 @cursor，让智能体帮你更新规则。
17. Skills 把领域知识、工作流与脚本打包起来，供智能体在相关时调用。
18. Skills 会在智能体判断“相关”时动态加载；这样既能保持上下文窗口干净，又能让智能体拥有专门能力。
19. 带有 hooks 的 Skills 还能与安全工具、密钥管理器以及可观测性平台集成。
20. 你可以贴一个设计稿，让智能体照着实现；智能体能看懂图片，并匹配布局、配色与间距。
21. 你也可以截取报错状态或异常 UI 的截图，让智能体去排查；这往往比用文字描述更快。
22. Commands 适合你每天会反复执行多次的工作流；把它们存成 Markdown 文件放在 .cursor/commands/，并提交到 git，这样全团队都能复用。
23. 对所有本地改动，打开 Source Control 面板并运行 Agent Review，对照主分支查看差异。
24. 对于重要改动，可以让智能体生成架构图；例如提示：“用 Mermaid 画一张展示我们认证系统数据流的图，包含 OAuth 提供商、会话管理与 token 刷新。”
25. 我们发现：让多个模型同时尝试同一个问题，再挑选最佳结果，会显著提升最终输出质量，尤其对更难的任务。
26. 在下拉菜单中选择多个模型，提交提示，然后并排比较结果；Cursor 也会建议它认为最好的方案。
27. 云端智能体很适合处理那些你本来会写进 todo list 的任务：
    • 工作中顺手记下的 bug 修复
    • 对近期代码改动的重构
    • 为现有代码生成测试
    • 文档更新
28. 与其凭感觉猜修复方案，不如用 Debug Mode：
29. 生成多个可能原因的假设
30. 为代码自动插入日志
31. 让你复现 bug 并收集运行时数据
32. 分析真实行为以定位根因
33. 基于证据做有针对性的修复
34. 关键在于提供足够详细的复现上下文；你描述得越具体，智能体添加的监测与日志就越有用。
35. 智能体的成功率会随着指令更具体而显著提升；对比“给 auth.ts 加测试”与“参照 tests/ 的模式，为 auth.ts 写一个覆盖 logout 边界情况的测试用例，并避免使用 mocks”。

如果你喜欢的话，不妨直接订阅这份电子报 ⬇️

2026-01-19 08:00:31

One helpful tip per day:)

Addy Osmani 分享了他在 Google 十四年里学到的经验：

1. 真正能脱颖而出的工程师，未必是最会写代码的人，而是那些搞清楚了代码之外一切的人：人、政治、协同、以及不确定性。
2. 但真正创造最大价值的工程师是倒推思考的：他们痴迷于深度理解用户问题，让解决方案从这种理解中自然浮现。
3. 真正理解问题的工程师，往往会发现：优雅的解决方案比任何人预想的都要简单。
4. 关键技能不是“我对了”，而是走进讨论去对齐问题、为他人留出空间，并始终对自己的确定性保持怀疑。
5. 强烈的观点，弱绑定地持有——不是因为你没有信念，而是因为在不确定性下做出的决策，不该和身份焊死在一起。
6. 先把事情做出来，然后把它做对，最后把它做得更好。
7. 发布一个让你略感尴尬的 MVP。一周的真实反馈，胜过一个月的理论争论。
8. 软件工程，是在加入时间和其他工程师之后发生的事情；在这种环境里，清晰不是风格偏好，而是降低运营风险。
9. 你的代码，是写给凌晨 2 点故障时维护它的陌生人的战略备忘录；优化他们的理解，而不是你的优雅。
10. “最适合的工具”，往往是“在多种场景下最不差的工具”——因为维护一座工具动物园才是真正的隐性税负。
11. 在大型组织里，很多决策发生在你未被邀请的会议中，基于你没写的摘要，由只有五分钟、却有十二个优先级的人做出。
12. 你不写的每一行代码，都是你永远不必调试、维护或解释的一行。
13. 问题不在于工程师不会写代码或不会用 AI 写代码；而在于我们太擅长写了，以至于忘了先问一句：这件事真的该存在吗？
14. 这带来一个职业层面的洞见：你不能把兼容性工作当作“维护”，把新功能当作“真正的工作”。兼容性本身就是产品。
15. 把弃用（deprecation）设计成迁移：给时间、给工具、给同理心。多数“API 设计”，其实是“API 退役”。
16. 在大公司里，团队是并发的基本单元；但随着团队数量增加，协调成本会几何级数增长。
17. 大多数“慢”，其实是对齐失败——人在做错误的事情，或用彼此不兼容的方式做正确的事情。
18. 资深工程师花更多时间澄清方向、接口和优先级，而不是“更快地写代码”，因为真正的瓶颈就在这里。
19. 面对不确定性时，把问题拆解成小块，并识别你当下能采取的具体行动。
20. 即便技术栈越叠越高，资深工程师仍会持续学习“更底层”的东西；不是出于怀旧，而是尊重这样一个时刻：抽象失效、凌晨 3 点你独自面对系统。用好你的技术栈。
21. 如果你觉得自己理解了某件事，试着把它讲得很简单；你卡住的地方，正是理解浅薄之处。
22. 教学，就是在调试你自己的心智模型。
23. 陷阱在于把它当作“热心帮助”，而不是当作有边界、可见、可衡量的影响来做。
24. “无价且不可见”，对你的职业生涯是一个危险组合。
25. 真正的对齐需要更长时间：你得真正理解他人的视角、吸收反馈，甚至在公开场合改变自己的想法。
26. 资深的做法是：对每一个指标请求，都给一对指标——一个衡量速度，一个衡量质量或风险；然后坚持解读趋势，而不是崇拜阈值。目标是洞察，而非监控。
27. 当领导者承认不确定性时，会向全场传递一个信号：这里是安全的，你们也可以承认不确定。
28. 那些在公司内外持续投资关系的人，几十年后仍在收获回报。
29. 你的工作不会永远，但你的人脉会。以好奇与慷慨去对待它，而不是交易式的忙乱。
30. 当该离开的时候，往往是关系为你打开下一扇门。
31. 删除不必要的工作，几乎总是比把必要工作做得更快更有影响力；最快的代码，是从不运行的代码。
32. 在你开始优化之前，先质疑：这项工作是否本该存在？
33. 如果人们花在“记录工作”上的时间超过“做工作”，那一定是哪里出了大问题。
34. 答案不是“不努力工作”，而是清楚你在交换什么，并有意识地做出选择。
35. 但这里有个希望：当学习能创造新选择而不只是新琐碎知识时，它会产生复利。写作——不是为了互动，而是为了清晰；构建可复用的原语；把伤疤沉淀成行动手册。
36. 二十一条经验听起来很多，但其实都指向几个核心：保持好奇，保持谦逊，并记住——工作始终关乎人：你为之构建的用户，以及与你并肩构建的同事。

如果你喜欢的话，不妨直接订阅这份电子报 ⬇️