MoreRSS

site iconDaily Productivity Sharing修改

每日生产力分享,及 DPS 周刊(无专用 RSS 故不添加周刊标签)。
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

Daily Productivity Sharing的 RSS 预览

Daily Productive Sharing 1348 - AI Workflows of Every

2025-10-29 08:00:48

Daily Productive Sharing 1348 - AI Workflows of Every

One helpful tip per day:)

Every.to 最近分享了他们内部是如何使用 AI 工具进行开发的,每个人都有自己的偏好:

  1. Claude Code 是一位“友善型开发者”,擅长拆解问题并解释推理过程;Codex 则是“技术型开发者”,更字面、更精确,常常一次命中正确方案。
  2. 通过 Figma MCP 集成,Claude 可以直接接入 Figma 文件,读取设计系统中的颜色、间距、组件,并将其转化为可运行代码。
  3. 他每次提交代码后,会在一份“学习记录”中写下两行心得并存入云端,几天后形成可回溯的近期记忆,用于再次喂给 AI 工具。
  4. 他把一天分为一个大任务和若干小任务,刻意避免被 AI 建议带偏。
  5. 他使用自制的 AgentWatch,当某个 Claude Code 会话完成时会提醒他,从而能同时运行多个会话而不失控。
  6. 上午专注执行,只用 Codex 和 Claude Code,不引入新工具,以确保交付不断。
  7. 下午进行探索,尝试新的代理、应用和功能。
  8. 他按功能规模分三层级规划编程方案:
    • 小功能:简单到可一次完成
    • 中等功能:跨几个文件并需评审(通常由 Kieran 负责)
    • 大功能:复杂构建,需要手工输入、深入调研和大量迭代
  9. Claude Code 是首选,因为它更可控、更自主;但对传统或“更极客”的功能,他会使用 Codex 或 Amp。
  10. 完成后,他运行命令让 Claude 审查代码,同时结合 Cursor 和 Charlie 等其他工具。
  11. 约 70% 的工作依赖 GPT-5 Codex 构建大型功能,然后用 Anthropic 模型细化完善。
  12. Danny 与 GPT-5 Codex 交流,以具体化实现方案,探讨二阶、三阶影响,并将洞见转化为项目里程碑。
  13. 他多数时间只用笔电或单屏幕;只有在实现视觉设计时,才开双屏并排展示 Figma 与代码。
  14. “如果不在 Linear 里,就等于不存在,”他常说。每个任务都带回溯链接,可追踪是谁提出及原因。
  15. 对于小 bug 或快速改进,他在 Linear 任务中添加上下文后复制到 Codex Cloud 启动代理任务。
  16. 对于大型功能,他会切换到 Codex CLI,在本地写 plan.md,作为项目蓝图与规范,边执行边与代理迭代。
  17. 他先运行 Codex 的 /review 命令扫描潜在问题,再手动对比前后版本验证变更。
  18. Codex 一直擅长非视觉逻辑,而 GPT-5-Codex 的到来让它在 UI 方面也同样出色。
  19. Nityesh Agarwal 喜欢保持紧凑、专注、干净;他的整个代理栈都运行在一台 MacBook Air M1 上。
  20. 在写代码前,他花数小时研究代码库并用 Claude 帮助绘制详细方案。
  21. 最近他缩短了 Claude 的“缰绳”,常中途打断让它解释过程,这虽减慢速度,却让 Claude 减少幻觉并提升他自己的开发思考力。

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

Daily Productive Sharing 1347 - How to Keep Winning

2025-10-28 17:41:18

Daily Productive Sharing 1347 - How to Keep Winning

One helpful tip per day:)

Amjad Masad 说世上没几件事比失败更让他恐惧,那种感觉糟透了,这也意味着他必须不断地练习如何不输。

  1. 除了死亡,几乎所有事情你都有机会东山再起。
  2. 首先,要知道死亡边界,反复思考最极端的下行场景,并把生存放在最高优先级。
  3. 他运营 Replit 八年,商业上一直没什么起色,但在现金流上从未进入红区,始终手握充足资金。
  4. 你几乎可以从任何困境中爬回来。
  5. 他们在教育和招聘领域的业务增长还不错,但那两个市场缺乏兴奋点,所以他们果断转向。
  6. 当你最终成功时,人们不仅会原谅你,还会加入你。
  7. 如果你已经下定决心去做某件事,那就不要轻易放弃,只要你还活着,你就仍然在游戏里。
  8. 成功往往只差两锤子。当你想放弃时,换一个计分板。
  9. 几乎在任何阶段,总有可以每天积累的小进展,让你感觉自己依然在赢,开始复利吧。
  10. 也许你在外部计分板上还没赢,但你始终拥有自己的内部计分板,用来衡量自己和团队,要有耐心。
  11. 大多数人都走显而易见的路,不想显得奇怪或不同,但真正的赢家往往就是那个与众不同的人。
  12. 做困难的事意味着你正在走一条少有人走的路,这条路充满风险。
  13. 每个“自建还是购买”的决策都要慎重,购买技术风险大,而自己构建能更快适应并找到长尾机会。
  14. 如果竞争对手在撒谎、欺骗或走捷径,那些手段只会带来短期优势,别被诱惑,保持专注。
  15. 按规则行事很难,因为那意味着你在做真正艰难的事,而这反过来会迫使你通过创新来解决问题。

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

Daily Productive Sharing 1345 - You Are Not Late

2025-10-24 08:00:35

Daily Productive Sharing 1345 - You Are Not Late

One helpful tip per day:)

Kevin Kelly 在2014年写下这篇文章,十多年后的今天再来回顾这些,很多都变成了现实,他确实富有远见 -- 2014 年,是在互联网上开始做点什么的最佳时刻——历史上从未有过比现在更好的时机去发明新事物:

  1. 就在那之前,我注意到 abc.com 这个域名还没人注册。于是我在为 ABC 公司顶层高管做关于数字化未来的咨询演讲时,告诉他们应该让楼下最聪明的技术员赶紧去注册自己的域名。结果,他们没有。
  2. 现在回头看,仿佛一波又一波的“拓荒者”已经把所有可能的地盘都推平开发完了,只剩下一些最棘手、最难啃的角落留给今天的新来者。
  3. 如果我们能坐上时光机,穿越到 30 年后的未来,再从 2044 年的视角回看今天,我们会发现——到那时主宰人们生活的那些伟大产品,大多数其实都是 2014 年之后才被发明出来的
  4. 2044 年的老前辈们还会告诉你另一件事:“你能想象 2014 年创业有多爽吗?”
  5. 那时的预期与门槛都很低,做第一个人很容易。然后他们会叹息道:“要是当年我们早点意识到一切都如此可能就好了!”
  6. 就是此刻,此分此秒——未来的人会回望今天,说:“啊,要是能活在那个时代该多好!”
  7. 过去 30 年为我们创造了一个令人惊叹的起点——一个可以用来构建真正伟大事物的坚实平台。不过,那些最酷的东西还没被发明出来,而且它们不会只是今天已有事物的“更多重复”。
  8. 你或许没有意识到,今天真的是一片完全开放的前沿。 这是整个人类历史上最适合开始的一刻。

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

Daily Productive Sharing 1344 - Agent Skills

2025-10-23 08:00:35

Daily Productive Sharing 1344 - Agent Skills

One helpful tip per day:)

Claude 刚刚发布了 Skills - 一种有组织的指令、脚本和资源集合,代理(agent)可以动态发现并加载这些内容,从而在特定任务上表现得更好:

  1. 与其为每个用例单独构建定制的代理,现在任何人都可以通过识别并共享自己的流程化知识,来用**可组合的能力(composable capabilities)为代理赋能。
  2. 最简单的情况下,一个 skill 就是一个包含 SKILL.md 文件的目录。该 yaml 文件必须包含一些必要的元数据:name 和 description
  3. 这些元数据构成了第一层“渐进式披露(progressive disclosure)”:它为 Claude 提供刚好足够的信息,让它知道在何种情况下应使用该技能,而无需将整个技能内容加载进上下文。
  4. 文件正文是第二层细节。如果 Claude 判断该技能与当前任务相关,它就会通过读取完整的 SKILL.md 将技能加载到上下文中。
  5. 技能目录中还可以包含其他附加文件,并在 SKILL.md 中通过名称引用它们。这些附加文件构成了**第三层(甚至更深层次)**的细节,Claude 只会在需要时才选择性地访问。
  6. 例如,把填表指令放在单独的 forms.md 文件中,可以让技能主体保持简洁;Claude 只会在真正填写表格时去读取 forms.md
  7. “渐进式披露”是让 Agent Skills 具备灵活性与可扩展性的核心设计原则。
  8. Claude 可以直接运行某个脚本,而无需将脚本或 PDF 加载进上下文。而由于代码是确定性的,这种工作流也因此稳定且可复现。
  9. 通过让代理执行具有代表性的任务,并观察其瓶颈或上下文需求,可以识别出技能能力的短板。然后有计划地构建新的技能以补齐这些不足。
  10. 当 SKILL.md 文件变得过于臃肿时,可以将内容拆分成多个文件并引用它们。
  11. 代码既可以是可执行工具,也可以作为文档存在。要明确 Claude 是应当直接运行脚本,还是仅将其作为参考读取进上下文。

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

Daily Productive Sharing 1343 - Advice for Principal Tech ICs

2025-10-22 08:00:06

Daily Productive Sharing 1343 - Advice for Principal Tech ICs

One helpful tip per day:)

Eugene Yan 认为任何长期不亲自下场的 Principal(首席工程师),都很可能在为失败埋下伏笔(短暂抽身可以,长期脱离不行)

  1. 没有哪一种风格更重要,你需要找到最符合你优势的那一种
  2. 到了这个层级,亲自写代码可能已不是你时间的最高效用。
  3. 你仍然应该写代码(保持与实际工作的联系),但你的核心职责已经转变为技术愿景、设计反馈、资源赞助、提供业务/产品/技术上下文、发现新问题、建立联系等。
  4. 即使你仍有 80% 的时间在写代码,你影响力最大的部分,其实是如何让所有人都变得更高效
  5. 更准确地说,你现在是个兼职的“全能型选手”:产品、设计、工程、科研、测试、招聘、财务、文化……无一不沾。
  6. 你的角色将更多涉及沟通、影响力与人脉连接
  7. 这些项目若要成功,必须建立起有效的共识与协作;要谨防把你的组织结构图“原样交付”给客户。
  8. 你不仅要说服别人你是对的,更要让他们在意到愿意去行动
  9. 你的听众从高层管理者到一线工程师都有——这是最难的工作之一,而且常常会失败。但既然你有更长远的视角与系统性的洞察,就仍然要去做。
  10. 有人说,他每提十份方案,大概三份会被采纳——他把这看作是极好的结果。

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