即刻App年轻人的同好社区
下载
置顶
当前实践下来最好的信息输入范式：
1. 碎片+trending：精心维护的一手信息源，包括github/huggingface/arxiv/筛选关注列表的X/高质量播客/top公司的前沿实践blog等
2. 整理+理解：与最SOTA大模型对话，现在即Claude
3. 思考+沉淀：阅读代表人类智慧精粹的经典书籍
这个过程类似神经网络对数据的处理，从浅层到深层，信息加工从具体到高度抽象，这个信息压缩过程可以简单建模成「信息->知识->认知」。
每天坚持这样做，可以有效缓解FOMO情绪。
1. 碎片+trending：精心维护的一手信息源，包括github/huggingface/arxiv/筛选关注列表的X/高质量播客/top公司的前沿实践blog等
2. 整理+理解：与最SOTA大模型对话，现在即Claude
3. 思考+沉淀：阅读代表人类智慧精粹的经典书籍
这个过程类似神经网络对数据的处理，从浅层到深层，信息加工从具体到高度抽象，这个信息压缩过程可以简单建模成「信息->知识->认知」。
每天坚持这样做，可以有效缓解FOMO情绪。
3 00
不要轻易将notion切到obsidian
最近在尝试从notion切到obsidian，目前试下来的最佳实践是：
- obsidian：笔记软件，查阅、快速编辑
- github：版本控制 + 云端存储
- claude code：ai助手
说几点我不适应obsidian的：
1. obsidian渲染表格样式效果很一般，稍微复杂一些的表格记录需求完全无法满足
2. markdown整体渲染样式，特别是对有/无序列表的渲染（缩进），让我感觉不舒服，比不上notion
完全不用为了数据主权而数据主权，为了ai native而ai native。原生md足够锋利，也足够简陋，使用上还需要配合更多最佳实践的积累，盲目从notion切换未必是明智之举
最近在尝试从notion切到obsidian，目前试下来的最佳实践是：
- obsidian：笔记软件，查阅、快速编辑
- github：版本控制 + 云端存储
- claude code：ai助手
说几点我不适应obsidian的：
1. obsidian渲染表格样式效果很一般，稍微复杂一些的表格记录需求完全无法满足
2. markdown整体渲染样式，特别是对有/无序列表的渲染（缩进），让我感觉不舒服，比不上notion
完全不用为了数据主权而数据主权，为了ai native而ai native。原生md足够锋利，也足够简陋，使用上还需要配合更多最佳实践的积累，盲目从notion切换未必是明智之举
9 00
科学vibe everything指南，我的claude code实践心得：
1. 不要试图当甩手掌柜，不要不关注具体内容，不要只是发布一些宏观指令、大模块指令。这么做的结果就是一方面cc并不能交付足够令我满意的结果，另一方面只会加重我的adhd而让实际办公效率更低。
当然，我一直在测试模型这方面的能力，即是否能够强大到自闭环地完成一个项目，而我不用关注任何实现细节，目前结论是不太行。
2. 把cc当做一个entry-level又无比博学的实习生来看待：
1. 项目调研：我来主导，它去执行具体的调研和建议。我需要思考每一个潜在的问题和它没有考虑到的地方，并反复质疑它，让它去尽可能多地执行调研，直到我认为没有更多有价值的信息增益为止。
2. 项目起步：基于当前已经满意的调研方案，快速搭建脚手架。我需要理解清楚脚手架中的每一处设计与实现，并实时与cc对话，不合理的地方需要质疑，直到它能给出令我信服的回答。
3. 项目开发：宏观层面还是需要我来主导（它提建议），把模块拆得适当小，再让它去做。拆得越细致，它完成得越好。随着context的累计，可适当放权。每一个它做完的模块都需要review以确保我对项目具体内容的掌控。
3. cc在干活的时候千万不要游离，而是也要去积极思考项目的设计，思考下一步需要做的事情。总之，专注必须仍然集中在项目上，集中在当前模块上。
4. 当cc每完成一项较复杂任务时，都可以强制让它再反思反思（以避免它上一轮执行有偷懒行为），反思直到反思不出有价值的信息增益为止，也可尝试采用其他模型（比如codex）来交替检查。
1. 不要试图当甩手掌柜，不要不关注具体内容，不要只是发布一些宏观指令、大模块指令。这么做的结果就是一方面cc并不能交付足够令我满意的结果，另一方面只会加重我的adhd而让实际办公效率更低。
当然，我一直在测试模型这方面的能力，即是否能够强大到自闭环地完成一个项目，而我不用关注任何实现细节，目前结论是不太行。
2. 把cc当做一个entry-level又无比博学的实习生来看待：
1. 项目调研：我来主导，它去执行具体的调研和建议。我需要思考每一个潜在的问题和它没有考虑到的地方，并反复质疑它，让它去尽可能多地执行调研，直到我认为没有更多有价值的信息增益为止。
2. 项目起步：基于当前已经满意的调研方案，快速搭建脚手架。我需要理解清楚脚手架中的每一处设计与实现，并实时与cc对话，不合理的地方需要质疑，直到它能给出令我信服的回答。
3. 项目开发：宏观层面还是需要我来主导（它提建议），把模块拆得适当小，再让它去做。拆得越细致，它完成得越好。随着context的累计，可适当放权。每一个它做完的模块都需要review以确保我对项目具体内容的掌控。
3. cc在干活的时候千万不要游离，而是也要去积极思考项目的设计，思考下一步需要做的事情。总之，专注必须仍然集中在项目上，集中在当前模块上。
4. 当cc每完成一项较复杂任务时，都可以强制让它再反思反思（以避免它上一轮执行有偷懒行为），反思直到反思不出有价值的信息增益为止，也可尝试采用其他模型（比如codex）来交替检查。
12 41
读完马斯克传，有两点深深吸引了我：
1. 知：清晰明确地认知自己心中的正义（包括了追求的理想、指导做事的第一性原理等）
2. 知行合一：剥离掉人性与情绪，像个机器一样坚定不移地贯彻自己心中的正义
这递进的两点能做到都是极难的，所以他的成就也将是划时代的、伟大的。
1. 知：清晰明确地认知自己心中的正义（包括了追求的理想、指导做事的第一性原理等）
2. 知行合一：剥离掉人性与情绪，像个机器一样坚定不移地贯彻自己心中的正义
这递进的两点能做到都是极难的，所以他的成就也将是划时代的、伟大的。
5 20
AI协同的软件工程实践思考：
1. AI的提效杠杆，会随着团队规模、项目复杂度、产品容错成本等因素的提升而显著衰减。所以理论上，AI对一个人的demo级项目提效最大，这也是OPC概念很火的原因之一。
2. 追求效率和敏捷的创业团队，按照闭环业务单元划分职能可能更优。一来AI加持下个人愈发全栈，闭环可行性提升；二来开发效率瓶颈往往卡在人员沟通（尤其是接口对接），闭环能绕开这个瓶颈。
3. AI能快速抹平应届生和工作一两年的初级程序员之间的差距——因为后者的优势往往只在「术」上。但根据抽象泄漏法则，ai反而会拉大初级和高阶程序员的差距：当一些抽象层被ai直接跨越，底层实现细节更容易被忽略，而这恰恰是高阶能力的分水岭。
4. 基于AI协同的软件工程实践值得被再次研究，即在复杂场景（团队规模大、产品业务复杂、项目庞大）下如何保证软件能够被安全稳定、可靠高效地构建。
1. AI的提效杠杆，会随着团队规模、项目复杂度、产品容错成本等因素的提升而显著衰减。所以理论上，AI对一个人的demo级项目提效最大，这也是OPC概念很火的原因之一。
2. 追求效率和敏捷的创业团队，按照闭环业务单元划分职能可能更优。一来AI加持下个人愈发全栈，闭环可行性提升；二来开发效率瓶颈往往卡在人员沟通（尤其是接口对接），闭环能绕开这个瓶颈。
3. AI能快速抹平应届生和工作一两年的初级程序员之间的差距——因为后者的优势往往只在「术」上。但根据抽象泄漏法则，ai反而会拉大初级和高阶程序员的差距：当一些抽象层被ai直接跨越，底层实现细节更容易被忽略，而这恰恰是高阶能力的分水岭。
4. 基于AI协同的软件工程实践值得被再次研究，即在复杂场景（团队规模大、产品业务复杂、项目庞大）下如何保证软件能够被安全稳定、可靠高效地构建。
4 01
尝试从解决核心问题的角度，阐释下我对ai agent工程的理解
prompt engineering：
1. 对话幻觉多
2. 对话正确的废话多
3. 对话解决较复杂问题能力有限
context engineering：
1. 上下文窗口有限
2. ReAct等工具调用范式对上下文窗口要求高
3. 对ai自主执行要求高，多轮亦步亦趋地解决复杂问题
harness engineering：
1. agent执行稳定性
2. agent执行安全性
3. 复杂、长程任务由与用户的同步关系改善为异步关系
prompt engineering：
1. 对话幻觉多
2. 对话正确的废话多
3. 对话解决较复杂问题能力有限
context engineering：
1. 上下文窗口有限
2. ReAct等工具调用范式对上下文窗口要求高
3. 对ai自主执行要求高，多轮亦步亦趋地解决复杂问题
harness engineering：
1. agent执行稳定性
2. agent执行安全性
3. 复杂、长程任务由与用户的同步关系改善为异步关系
2 00