ginobefun

统计数据

279

文章

0

粉丝

0

获赞

17170

阅读

11小时前

关电脑前最后一刷，发现孟岩和李继刚竟然坐下来聊了三个多小时。这两位是我长期关注的博主，一个做投资，一个玩 prompt，一个从理性走向心灵，一个从心灵走向结构，好奇他们的碰撞。

13小时前

在 Claude/ChatGPT 里输入这个提示词有惊喜 --------------- 我希望您根据您所了解的所有信息，为我创建一个全面的个人背景文件。我想保留一份我们共同建立的背景便携副本——包括我的偏好、工作流程、项目，以及您了解到的关于我如何工作的任何其他内容。请从您的记忆系统、我们的对话记录、我的自定义指令以及您发现的任何模式中提取信息。使用以下部分结构化输出。跳过任何不适用于我的部分。 <身份> 姓名，职位或角色，公司或组织我每天实际做什么（不仅仅是头衔）行业和领域 </身份> <技术环境> 操作系统和硬件我经常使用的软件、工具和平台编程语言或技术技能（如适用）您知道的具体版本、配置或设置 </技术环境> <当前项目> 我目前正在进行中的工作您知道的短期目标和长期目标经常性任务或工作流程 </当前项目> <专业知识> 我深入了解的话题我正在积极学习的话题初学者领域或者需要额外解释的问题 </专业知识> <沟通偏好> 我的回复结构喜好（长度，格式，语气）我要求您做或者不要做的一些事情格式偏好（列表 vs 散文，技术深度等）重复纠正或者让我反感的问题 </沟通偏好> <写作风格> 我的写作方式（正式, 随意, 技术性等）声音特征观察到的信息提到过的一些具体风格规则 </写作风格> <关键人物> 合作者, 团队成员或客户，我经常提到的人物报告结构或重要职业关系曾请求帮助与之交流的人物 </关键人物 > <个人背景 > 位置和时区与我们工作相关的兴趣爱好或细节限制条件或偏好的问题 (无障碍需求 , 日程安排等 ) </个人背景 > <固定指令 > 来自我的自定义说明书或系统提示的内容一直遵循的规则已成为永久指令的重复更正 </固定指令 > < 工作流模式 > 通常如何使用你 (头脑风暴 , 编辑 , 编码 ,研究等 ) 常见请求类型和处理方式一起开发出的多步骤过程 </ 工作流模式 > 请详细说明。我需要完整快照，而不是摘要。如果你知道，请包含在内。保持输出中的标签，以使其保持有序且可移植。

14小时前

这个域名也太差劲了，没有想尝试的欲望 😅

21小时前

BestBlogs 也有 RSSHub 路由了，感谢两位开发者 🫰

2天前

最近的编码组合：Opus 负责需求分析和开发自测，Codex 负责审查和找茬。 Opus 4.6 具备更强的自主规划和发散创意能力，能独立探索代码库、确认需求、设计方案、生成高质量文档，擅长从 0 到 1 的开发，已经是一名综合能力很强的「高级工程师」。而 Codex 5.3 有时则显得「刻板」，深度挖掘和自动思考不足，但它对代码质量和架构问题很敏锐，能发现很多异常场景和性能隐患，更像一名挑剔的「质量工程师」。

2天前

陪娃看球现场氛围不错

3天前

去年 Claude Code 刚出来的时候，我主要用 Cursor 写代码，终端里敲自然语言感觉太粗糙了。一年下来，使用比例从 2:8 彻底反转成了 8:2，大部分代码都在 Claude Code 里完成。我想，变化的根源不是哪个工具更好用，而是对谁在干活这件事的预期变了。以前习惯用 IDE 操作，能够看到每个类和函数，AI 只是辅助。现在模型能力到了一个临界点，能可靠地理解需求、读代码、改文件、跑测试、修 bug，这个时候更需要的是描述意图和验收结果，而不是盯着每行代码。 Cursor 其实也在拼命转型，2.0 默认就是 Agent 布局，还上了多 Agent 并行等实用功能。但从 IDE 范式里长出来的 Agent 体验，天然带着编辑器时代的包袱。这不是做得好不好的问题，是产品形态本身决定了什么样的工作方式。

3天前

在 Vibe Coding 的时候，集成测试值得投入更多的精力，我发现 TDD 的单元测试和一堆 Mock 虽然执行很快，全绿时能给人舒服的感觉，但是以真实的用户故事和使用场景为核心的端到端的测试能够发现更多的问题，对代码的可测试性提出了更高的要求，我最近在使用 SDD 开发时，让 AI 编写了一系列的集成测试用例，在生产环境部署前确保全部通过，这个习惯帮我提前发现了很几个问题。

3天前

学习的核心是「强制建立连接」。拒绝被动输入，通过提取 15 个关键词手动绘图，将新知识强行织入原有认知网。大脑不记孤立碎片，只留逻辑联系。通过不断简化重组，让知识像雪球般自发增长。消化的深度，直接决定了记忆的强度。

4天前

一次流量高峰导致的 VPS 限制与恢复最近 BestBlogs 流量激增，加上代码一个小 Bug，导致服务器 CPU 瞬间拉满。结果触发了服务商的「保护机制」，核心数被强制削减到 1 核，导致系统差点陷入死循环。赶紧将部分服务迁移以平摊负载，并及时与服务商沟通说明情况。目前 CPU 配额已恢复，虚惊一场。服务器端的监控要赶紧补起来。😅

4天前

Agent 时代的双环飞轮：执行过剩之后，什么才真正值钱？最近读到一篇关于 Agent 时代价值重构的文章，触发了一些思考。我试着把核心逻辑画成了一张系统动力学的图，越画越觉得里面藏着一些对开发者很重要的东西。 Agent 让执行成本暴跌之后，会出现两个速度完全不同的循环。外环是市场层面的快循环。执行成本降低，内容和应用被批量生产，信噪比急剧下降，筛选需求暴涨，判断力的价值随之上升。这个循环转得很快，所有人都能感受到。内环是个人和团队层面的慢循环。你通过快速迭代验证自己的判断，把验证过的好判断编码进系统和工作流，让它脱离你本人持续运转，产生复利。这个循环慢得多，但只有跑通内环的人才能真正积累壁垒。大多数人会被外环的速度裹挟，不断追新工具、造新东西，但始终没有进入内环。真正的分水岭在于你能不能把外环中捕捉到的信号，沉淀为内环中可复用的判断资产。但这个飞轮不是无限正向的，有两个隐藏的风险需要注意。一个是判断锁定。编码进系统的判断会形成路径依赖，环境变了但系统还在按旧判断跑，改动成本越来越高。所以每个被编码的核心判断都需要预设一个重新审视的周期。另一个是深度陷阱。快速迭代给你的是短期信号，但很多真正重要的方向需要长期信号才能验证。如果只看两周内的数据反馈，你可能会过早放弃一个本该坚持的方向。引入慢信号的验证体系，追踪深层行为变化而不只是表面指标，这件事和快速迭代同样重要。对开发者来说，不要只顾着用 Agent 造东西，要有意识地把你验证过的判断固化到系统里，同时给这些判断留好可调整的空间。跑得快很重要，但跑对方向并且把方向感编码成可复用的资产，才是这个时代真正的复利来源。

5天前

在公司里用就手机作为移动热点网络老是掉线，之前听了小宇宙中兴移动 Wifi 产品经理的播客，入了一个 U30 Pro，网速比我自己手机还快一些

5天前

这位说的情况可能很普遍。大部分公司引入 AI 之前就管理混乱、执行力差、流程繁琐，AI 进来之后只会把这些问题放大。本来摸鱼的人有了更顺手的工具摸鱼，本来代码质量一般的人开始批量生产垃圾，而真正在做事的人被淹没，熬不住就走了。这些问题，根源不在 AI，在组织和人。AI 只是把原本存在的问题暴露得更快、更明显。一个执行力强、判断力好、真正想做事的团队，现在确实可以用更小的规模做出以前做不到的东西，在最近的项目里有切身感受。 --------- 大家都在说自己团队效率超高，唯一的瓶颈就是写代码太慢。现实是这样的： - 你的公司本来就没几个好想法。过去"做个东西要花大价钱"其实是件好事，能帮你筛掉那些根本不值得做的需求 - 大多数员工没动力拼命，他们只想把今天的活干完，然后回家过日子 - 他们用 AI 不是为了变成 10 倍效率的工程师，只是为了用更少的力气把任务糊弄过去 - 团队里那两个真正在认真干活的人，正在被所有人甩出来的 AI 垃圾代码压垮，他们快撑不住了，很快就会走 - 就算你产出再快，还是会被层层审批、各种流程、以及把东西真正上线要面对的一堆现实问题死死卡住 - 你们 CFO 一脸懵：每个工程师每个月多出来 2000 美元的 AI 账单，到底买到了什么？

5天前

真正的学习发生在动手的那两小时听演讲、看 demo，感觉自己懂了，但其实还停在认知层。真正产生"原来这东西真的有用"那种顿悟，往往是腾出两小时被迫动手之后的事。从理解到使用之间有一道坎，跨过去只有一个办法：做。等三个月，做前 10% 就够了 AI 圈每天都有新玩意儿，FOMO 是真实的。但有个简单的应对策略：只学已经存在超过三个月的东西。让爱折腾的人先踩坑，等市场消化完再跟进。做前 10% 比做前 1% 划算得多，前 1% 是 tinkerer 和内容创作者的游戏，实干家不需要玩。学习能力是一种肌肉，先练再谈方向很多人卡在"该学什么"这个问题上，结果什么都没学。一个更好的思路是：先学你感兴趣的任何东西，把习惯建起来，方向之后再说。学 AI 也好，学网球也好，本质上练的是同一项技能，练什么不重要，重要的是先动起来。

6天前

最近也是这个思路，CLAUDE.md 只会无法被删除的内容，通过目录索引找到子 CLAUDE.md 或关联文档，大幅减少上下午的占用

1周前

Claude Max 套餐还挺耐用，自认为很高频的使用 Opus 4.6 模型，周限额才使用到 60%，还可以继续撸

1周前

在使用 AI 辅助开发的过程中，我发现 Vibe Coding 的灵活性与 SDD 的规范性并不冲突，关键在于找到合适的结合点。以下三个规则是我从实践中总结的体会。 1. 大功能先做快速原型当开发周期超过 2 天时，直接在脑海中构思完整方案很容易遗漏细节。与其在写代码后才发现问题，不如先用 Claude Code 快速搭建一个可运行的原型。这个原型不需要完美，只要能验证核心流程是否走得通即可。验证通过后，再进入 SDD 流程编写完整的 Spec。这样做看似多了一步，实则避免了大段的返工。 2. 关键节点进行架构对话在编写 01_requirement.md 或 02_interface.md 之前，我会先和 Claude 进行一次架构对话。主要问三个问题：这个方案我能向别人解释清楚吗？哪个模块最容易出问题？需求、设计、安全、运维方面有没有遗漏？这个对话通常只需 5 分钟，却能帮我发现很多盲区。 3. Bug 修复提供完整上下文遇到问题时，一句这个功能有问题对 AI 帮助甚少。一个结构化的方式能把问题说清楚：我做了什么操作、期望得到什么结果、实际看到了什么错误。这三个要素能让 AI 快速定位问题，而不用大量推理和猜测。总结一下，这三个规则可以用最小成本验证想法，用对话弥补盲区，用清晰表达加速解决。

1周前

开了 Claude Max 订阅，使用 SSD 驱动开发，明显感觉到最近几次 Spec 开发得非常顺畅，先理解需求-编写PRD-写设计文档-代码实施-编写测试用例-自动验证-Review优化改进，最后再人工操作和验证，提出问题和改进建议，不断的循环改进，代码写得飞起

1周前

Greg Isenberg 与 Internet Vin 讨论如何基于 Obsidian 和 Claude Code 构建「第二大脑」。虽然我自己觉得 Obsidian 太复杂，但是里面的一些思路和我自己最近的尝试不谋而同，就是通过合理的目录和结构整理项目中的需求、顶层设计、详细Spec文档、中间的决策过程和日志，形成一系列的具有层级结构的、可追溯的、相互引用的 Markdown 文档库，即时再复杂的任务和需求也能游刃有余。

1周前

用 AI 做了一件过去要花几周的事 BestBlogs 运营了 400 多个 RSS 订阅源，每日处理几百篇内容。表面看起来运转正常，但有三件事一直悬在那里：某个订阅源的内容质量在悄悄滑落，每周要手动翻几百篇文章挑选推送内容，处理管线的健康度也从来没有系统性的度量。这三个问题不是不知道怎么解，而是一直排不上优先级，就这么搁着。最近的思考就是优化这类知道该做、一直没人做的运营工作，能不能让 AI 定期自动完成，人只负责看结果？这次用 AI 辅助完成了 5 个异步运营 Job 的完整实现，包括订阅源质量监控、Newsletter 选题建议、内容质量月报、技术趋势洞察，以及知识维护的脚手架。从 Spec 文档到后端 43 个 Java 文件，再到前端 4 个 Admin 页面、12 个 API，走下来有几个真实感受。 AI 处理结构化的重复工作很稳。15 个 ConfigKey、4 套 Entity/Repo/DTO、12 个端点，这类有清晰模式可循的代码，几乎不需要反复调整。最有价值的部分不是代码本身，是写 Spec 时逼自己把事情想清楚的过程，每个 Job 读什么数据、怎么处理、往哪写，全想明白之后，后续几十个文件的生成才有可靠的参照。文档在这里起的作用，不是存档，而是压缩上下文、减少偏差。 AI 没解决的问题同样值得记录。订阅源质量分析里的指标计算用了占位实现，分数阈值先拍一个，这是真实的技术债务。骨架搭得很快，但业务细节里那个数到底怎么算准，还是要人去推敲和持续实验。一个感受是，对个人项目或者小团队而言，AI 在工程侧最实用的价值可能就是这类场景，把知道该做但资源不够的运营工作，变成机器每周自动跑一遍、人来 review 结论。主动监控替代被动响应，这个转变本身就值得做。

3周前

现在写文档大多数是留给 Agent 看的

1个月前

深有同感

1个月前

Clawdbot -> Moltbot -> OpenClaw 刚发完本周的周刊，发现又改名了😅

1个月前

Ralph Loop 是一种通过工程化持久性克服 LLM 自我评估局限的自主编程范式。利用外部循环和 Stop Hook 机制，强制 AI 结合 Git 历史和自动化测试进行持续修正。

1个月前

交流群里这个生图有点意思😂