WquGuru🦀

统计数据

10

文章

0

粉丝

0

获赞

122

阅读

5天前

朋友看到这条说很有共鸣，他们团队是很典型的互联网时代Scrum：6人小分队，1个PO、1个SM、3-4个研发，每天15分钟站会、周例会、Sprint规划、回顾、精炼，会议几乎占掉一半时间需求虽然有llm参与创建，但是质量完全不行，需求细分、优先级调整、bug跟踪则全靠人肉压根没AI化，回顾会经常变成集体吐槽却没什么实质改进。最难的是创新几乎为零——大家忙着赶交付、堵漏洞，根本没精力去试新东西，新想法基本只能下班自己偷偷摸索看了openai那种小团队高自主、敢赌高风险项目的玩法，和anthropic死盯编码主线、连side project都能滚出行业标准的深度迭代，突然觉得这套“敏捷”在AGI时代真有点跟不上了，会议和流程其实在悄悄吃掉创造力今年小步试错的方案：砍掉部分固定会议，设置流程自动化中llm参与度和参与质量的软指标，给团队留出时间去跑点小实验或者深挖一个方向

2周前

8月份那会儿，mcp 方兴未艾，spec coding还在幼儿园阶段，斜杠命令也才刚刚起步，agents和subagents的组合还乱糟糟的，ide整合也各行其道，skills甚至没有诞生那时候我就觉得，ai写代码真能让人效率翻10倍，但这10倍可不是天上掉下来的，得有套靠谱的玩法，不然用着用着就累得要死，还老觉得自己跟不上了 karpathy昨天这条推说到了大家心坎里：突然塞给我们一个超强的外星玩意儿，却连个说明书都没有；一堆agents、prompts、contexts、memory、tools、plugins、skills、hooks、mcp、lsp、工作流，得自己摸索怎么对付它们的随机、爱出错、看不透，还一天一个样，不然要不burnout，要不掉队仔细看了看评论区，大家一致的观点有：验证还是最头疼的；新人没老一套包袱反而玩得转；代码生成快了，瓶颈变成“我到底想干啥”；软件工程的老本行功底仍然还是王道当时我学习经典“12 factor app”的路子，整理出AI Coding的4阶段12原则，目的是从瞎捉摸变成稳稳地把AI使唤得转，4个月过去，时间验证这12原则仍然是长期有效的：阶段1 准备：单一真源、提示词先行、上下文洁净、预期重调——把prompts和contexts管得明明白白，别让旧习惯拖后腿，定时更新prompt，跟上新模型阶段2 执行：人类在环、任务块化、并行流动、验证优先——代码标准一点不能降，ai写的也得过测试关，小块小块来，别一下翻车阶段3 协作：负载预算、流保护罩、可复现性、意图清晰——别把自己累死，记好每一步，先想清楚要啥再让ai上，别被随机性搞崩阶段4 迭代：休息反思、技能均衡、好奇文化、日常实验——每天抽空玩玩新东西，多跟大家聊聊经验，老问问“为啥”和“还能再牛点吗” 不论你是职业工程师，还是刚入门，这套东西都是能陪你走长路的框架，帮你在这一波冲击中站得住，还能使劲往前冲🫱

4周前

某些公众人物，尤其是投资圈人物接受访谈时，往往由于自身利害关系，以及为了表示对业内大佬或大公司的尊重或者避免纠纷，常会拒绝回答某类问题，或者以圆滑的方式回答，而这种表述又比较难以察觉其真实意图和理念例如张小珺《商业访谈录》Episode 122（朱啸虎现实主义故事的第三次连载：人工智能的盛筵与泡泡）：关于“六小龙”（月之暗面、智谱等创业大模型公司）的终局判断当被问到“六小龙的终极会是什么样？”时，朱啸虎的回答表面上是技术分析——“看不出来了现在？大厂的token给的太便宜了，创业公司怎么做商业化？它本身就是云服务的一部分，价格又给得非常便宜，你靠什么去竞争？它的模型又足够好” 但结合上下文可以发现隐藏的真实意图：朱啸虎早在2024年明确表态“绝不投资任何一家大模型公司”，且在报告中甚至提到“AI六小虎最好的结果是卖给大厂” 他反复向LP强调“感谢我们没在基础模型公司上浪费一分钱” 当被追问“大模型公司像上一轮周期的哪些公司？”时，他说“和四小龙很像的，甚至比四小龙更差……今天可能真的连商业化都不容易” 然而当主持人总结“你都觉得有可能会是泡沫？”时，他立即撇清：“这不好说，这不是我说的，这是你说的。我只说我们这几个赛道的共识都太集中了” 真实意图分析：朱啸虎其实非常看衰六小龙的商业化前景，但出于以下考虑采取了极其圆滑的表述方式： - 避免直接得罪行业内的创业者和其他投资人； - 为自己“不投大模型”的策略做辩护，同时保留余地（如果未来六小龙成功可以说“我只是说看不出来”）； - 用问句和反问的方式表达悲观态度，而不是断言；当主持人试图让他下明确结论时立即撇清关系针对上述场景，我设计了一个专属prompt，名为“公众人物访谈真实意图理念整理器” 这个prompt能指示AI利用网络搜索工具，系统收集目标人物的多场访谈记录，进行时间线前后对照，按主题分类整理原话，并基于公开投资记录等客观因素，谨慎分析潜在表述背后的可能意图，同时保持中立，避免臆测我用这个prompt，生成了一篇朱啸虎2024-2025.12无偏见访谈观点报告：

2个月前

追求生态用python 追求全栈用ts 追求效率用go 追求性能用rust 就是这么简单

#生态 #Python #全栈 #TS #效率

2个月前

仿盘阶段2 Qwen3 Max 终于对持仓近 100 小时（99.56h）的 BTC 仓位进行了大幅减仓，净盈亏 +$8,176.28！随着止盈止损的调整，夏普率也来到了 0.813 开源项目的前端部分已完全完毕，后端开始开发，应该是目前复刻最完整的版本，GitHub fork+star 达 176： - GitHub 地址： - 预览网站：阶段 2 支持以下新特性： 1. 排行榜：新增模型详细指标，包括手续费、胜率、交易笔数、夏普率等 2. 模型详情页：提供更具体的模型分析、当前持仓情况、以及最近 25 笔成交记录 3. UI/UX 优化后端部分： 1. Dummy 接口已 ready 2. PostgreSQL 数据表和缓存已 ready 更多特性待你探索，项目仍在持续优化中。欢迎大家 star/fork，戳戳评论

币圈“1011”六倍崩盘：高杠杆爆仓潮，谁在裸泳？· 6476 条信息

#Qwen3 Max #BTC仓位减仓 #净盈亏+$8,176.28 #开源项目复刻 #排行榜

2个月前

仿盘阶段1 一觉醒来Qwen3的资产余额又到了$15000以上，DeepSeek超过$12000且有继续上涨的迹象我的仿盘的前端部分也已经开源，应该是目前为止复刻最完整的版本，欢迎star：预览网站：支持的特性有： 1. 资产曲线完美复刻 2. 持仓情况 3. 模型对话历史部分支持中文 4. 成交纪录 5. 亮色和暗色主题更多特性待您探索，同时还在不断优化中，欢迎戳戳评论

币圈“1011”六倍崩盘：高杠杆爆仓潮，谁在裸泳？· 6476 条信息

#Qwen3 #DeepSeek #开源 #资产余额 #中文支持

4个月前

已经五天没发推，也把手机上的X卸载了。原因是最近Claude Code的Vibe Coding差点让我崩溃。这两个月，我几乎把全部时间都献给了它。不管是个人项目还是工作项目，我最高同时跑了三个项目，七天十二小时无缝切换。有人问我怎么能这么拼，我告诉他们：Vibe Coding让我觉得自己像个超人，代码随叫随到，效率爆表。但真相是，这种“超能力”并非毫无代价。第一个坑是——我连休息时间都逃不了这场码字的“噩梦”。甚至睡觉前，我的脑子还在纠结代码逻辑。身体和精神开始报警，疲惫积累得无法忽视。第二个坑是，我过度依赖Vibe Coding，认为它能解决一切。一次交易数据页面字段异常，我第一反应是让Claude帮我分析。可它给了我一堆代码片段，分析了半天，却没触及症结。最后，我放下机器，回归最原始的排查法——手动跟踪前端调用链路，一步步找出问题所在。才发现，那不过是一个简单的配置错误。这个经历让我明白，再强大的工具，也终究是人背后的辅助。不能被工具支配，而是要驾驭工具。技术的终极奥义，是用头脑去解决问题，而不是盲目依赖。所以，这几天卸载X，断开信息洪流，只为给自己一个空间，重新好好思考、休息和成长。正确认识工具的价值和局限，别被工具绑架，才能做个真正自由的dev/researcher。

AI编程工具激战：Claude Code、Gemini Cli崛起· 1256 条信息

#Claude Code #Vibe Coding #过度依赖 #技术反思 #工作生活平衡

4个月前

越早意识到下面这点的Engineer越有长远优势：当AI生成代码有问题时，你不应该自己检查，自己改，而应通过： prompt层面：更详尽的任务规划，更细分的TODO… 工程层面：e2e、单测、强类型语言… 给到AI更多线索和约束，完全让他自己迭代简而言之就是不要与AI发展的趋势对抗，培养工程、架构、规划能力，而不是编码能力

#AI浪潮：重塑就业，风险暗涌？· 140 条信息

#AI #代码生成 #工程能力 #架构能力 #任务规划

5个月前

分享一个Claude Code全局提示词（也适用于Augment/Cursor等等），有架构师附身之奇效： ## Code Architecture - 编写代码的硬性指标，包括以下原则：（1）对于 Python、JavaScript、TypeScript 等动态语言，尽可能确保每个代码文件不要超过 200 行（2）对于 Java、Go、Rust 等静态语言，尽可能确保每个代码文件不要超过 250 行（3）每层文件夹中的文件，尽可能不超过 8 个。如有超过，需要规划为多层子文件夹 - 除了硬性指标以外，还需要时刻关注优雅的架构设计，避免出现以下可能侵蚀我们代码质量的「坏味道」：（1）僵化 (Rigidity): 系统难以变更，任何微小的改动都会引发一连串的连锁修改。（2）冗余 (Redundancy): 同样的代码逻辑在多处重复出现，导致维护困难且容易产生不一致。（3）循环依赖 (Circular Dependency): 两个或多个模块互相纠缠，形成无法解耦的“死结”，导致难以测试与复用。（4）脆弱性 (Fragility): 对代码一处的修改，导致了系统中其他看似无关部分功能的意外损坏。（5）晦涩性 (Obscurity): 代码意图不明，结构混乱，导致阅读者难以理解其功能和设计。（6）数据泥团 (Data Clump): 多个数据项总是一起出现在不同方法的参数中，暗示着它们应该被组合成一个独立的对象。（7）不必要的复杂性 (Needless Complexity): 用“杀牛刀”去解决“杀鸡”的问题，过度设计使系统变得臃肿且难以理解。 - 【非常重要！！】无论是你自己编写代码，还是阅读或审核他人代码时，都要严格遵守上述硬性指标，以及时刻关注优雅的架构设计。 - 【非常重要！！】无论何时，一旦你识别出那些可能侵蚀我们代码质量的「坏味道」，都应当立即询问用户是否需要优化，并给出合理的优化建议。

AI编程工具激战：Claude Code、Gemini Cli崛起· 1256 条信息

#代码架构 #代码质量 #代码优化 #坏味道 #架构设计

6个月前

Anyrouter把Claude Code请求响应都存本地了，这是打算把数据卖给Trae或Gemini？