ginobefun

统计数据

248

文章

0

粉丝

0

获赞

2953

阅读

3个月前

这两天高强度地折腾服务器，Warp 几乎全程在线。无论是安装 Nginx、调试部署脚本，还是申请 SSL 证书，和 AI 聊几句基本就搞定了。感觉以前需要查半天文档的活儿，现在几分钟就解决了。当然，越是方便，越要注意安全，关键信息千万别在对话里裸奔。

#服务器折腾 #Warp在线 #AI辅助 #效率提升 #注意安全

3个月前

一提到「公司政治」，多数工程师的第一反应是远离。但如果有一种方法，既能让你告别内耗，又能让你的技术方案获得高层鼎力支持，你是否愿意了解？这篇博客的作者认为，工程师最大的错误就是试图去玩一场自己不擅长的「权力的游戏」。相反，真正有效的策略是看懂规则，然后选择在正确的时间，将你早已准备好的技术方案，递到最需要它的高管手中。这篇文章揭示的就是这种「等风来」的智慧，一种更适合技术人的生存法则。 --------- 作为一名专家工程师，我是如何影响公司政治的作者：sean goedecke 原文：很多软件工程师对公司政治都抱着一种听天由命的态度。他们觉得掺和进去纯属白费力气，因为： - 技术决策的背后往往是纯粹的私心，一个善意的工程师根本影响不了。 - 那些手握重权的利益相关者，通常既愚蠢又混乱，你根本没法搞懂他们的真实需求，更别提拿出解决方案了。 - 所谓的政治博弈，靠的是工程师压根接触不到的内部消息。你要是贸然参与，只会在里面瞎转悠。 - 管理层和高管们大部分时间都在搞政治，而工程师大部分时间都在搞技术。所以工程师还没下场，就已经输在了起跑线上。总而言之，大家普遍认为，软件工程师根本就不是玩这套游戏的料。没错！工程师要是觉得自己也能像《权力的游戏》里那样运筹帷幄、搞阴谋诡计，那可就大错特错了。你的那点小九九很快就会被识破，然后被别人利用，让你吃亏，让他们获利。玩心计需要经验和权力，这两样东西工程师都没有。事实就是，在大公司里，软件工程师往往是政治博弈中的棋子，而不是棋手。不过，不玩权谋，不代表你不能参与政治。顺势而为，而非凭空创造最简单的方法，就是主动投入，把一个高调的项目做成功。这差不多是你本来就该做好的分内工作。如果公司正在大力投资某个新项目 —— 比如现在最火的 AI 项目 —— 你用自己的技术把它做成，对于主导这个项目的副总裁或高管来说，就是送上了一份政治大礼。作为回报，你也能得到高管们能给的好处：奖金、晋升上的帮助，以及未来参与更多明星项目的机会。一个稍微难点但让你更有主动权的方法，是让你自己的私藏项目搭上高层关注的顺风车。比如，你早就想把某个现有功能抽出来做成一个独立服务。想实现它，你有两种办法。难的办法是消耗你自己的政治资本：到处游说，争取支持，告诉你的经理这对你有多重要，慢慢磨到大家都不反对了，项目才可能被正式批准。简单的办法是，让某个高管用他那多得多的政治资本来推你的项目。你要做的，是等到公司自上而下地推行某个目标，而这个目标正好和你的项目方向一致时（比如，在发生了一次重大线上事故后，公司开始强调可靠性）。这时候，你再跟你的经理提议，说你的项目可能很适合这个大方向。如果你判断对了，你的整个组织都会支持你的项目。而且，这非但不会消耗你的政治资本，反而会增加它。准备好你的“弹药库” 公司的关注点总是一阵一阵的。强调“可靠性”的时候，VP 们都急于“做点什么”。他们想找一些听起来靠谱的可靠性项目来投资，因为他们需要向自己的老板汇报工作，但他们自己又没能力凭空想出来。所以，工程团队提上来的任何建议，他们通常都很乐意买单。反过来，当公司的注意力在别的地方 —— 比如要发布一个重磅新产品 —— 他们最不希望看到的，就是工程师把时间花在客户完全感知不到的、为了内部可靠性而做的重构上。所以，如果你想在科技公司里把某件技术性的事情做成，你就得学会等风来。一个好方法是提前准备好几个不同方向的技术方案。厉害的工程师在日常工作中就会有意识地做这些储备。比如，你可能已经有了一些初步计划： - 把计费代码从缓存 API 调用改成基于 webhook 更新存储数据。 - 用 Vite 替换掉那个老掉牙的手摇构建流程。 - 把一个笨重的、高流量的 Python 服务用 Golang 重写。 - 把那个加载缓慢的、支撑着公开文档的 CMS 前端，换成一个快速的静态网站。当高管们开始关心计费问题时，你就可以把计费重构方案作为可靠性改进提出来。当他们关心开发者体验时，你可以建议替换构建流程。当客户抱怨性能时，你可以指出用 Golang 重写是个好选择。当 CEO 看了眼公开文档，觉得很丢人时，你就可以提议把它重建成静态网站。最关键的是，无论当下的“月度风向”是什么，你手里都要有一个详细、可行的方案随时准备好。你的职责所在不管你做不做这些准备，反正总得有项目被推行。但如果你不这样做，你就没法控制到底是什么项目。依我之见，这恰恰是公司做出最烂技术决策的时刻：当“必须做点什么”的政治需求，撞上了“没啥好点子”的窘境。没有好主意，那烂主意也只能凑合了。但没人想要这种结果。高管们很难受，因为他们得把一个令人失望的技术成果包装成成功案例去汇报；工程师们也很难受，因为他们得把时间和精力浪费在错误的事情上。如果你是一个非常资深的工程师，VP 们私下里会把这笔账算在你头上。而且他们这么做是对的！在正确的时间点，准备好正确的方案，这本身就是你的职责。你可以从两种角度来看待这一切。从悲观的角度看，我这是在建议你把自己变成一个方便的工具，好让那些管理公司的野心家们，在他们无休止的内部权力斗争中利用你。从乐观的角度看，我这是在建议你让高管们去设定公司的总体优先事项 —— 毕竟那是他们的工作 —— 然后你再把自己的技术规划与之对齐。无论你怎么看，只要能在正确的时间点推动正确的计划，你就能实现更多的技术目标。

#公司政治 #工程师 #技术方案 #高管支持 #生存法则

3个月前

韩国政府这波操作真是惊为天人。他们轰轰烈烈地建了个国家级云盘 G-Drive，强制 75 万公务员使用，然后在一场火灾中发现…… 这系统竟然没备份！数据被一锅端，实现了真正意义上的物理删除。这完美绕开了 IT 入门第一课的所有知识点，把“3-2-1 备份原则”硬是执行成了“0-0-0”。这背后仿佛能看到有人为了省下「异地备份」那笔看似多余的预算，而签下大名的场景。这故事告诉我们，有时候最可怕的不是天灾，而是某个省钱的“英明”决策。

#韩国政府 #G-Drive云盘 #数据丢失 #缺乏备份 #预算决策失误

3个月前

OpenAI 开发者日 2025，Sam Altman 主题演讲的四件事： - Apps SDK：在 ChatGPT 内部构建应用。 - Agent Kit：简化智能体的创建。 - Codex：一个能自主编写、重构、审查软件的智能体。 - 新模型 (GPT-5 Pro, Sora 2)：更强的大脑和新的感官（视频、音频）。这是一个典型的产品发布会：提供新工具，展示新能力。但这不是重点。

#OpenAI开发者日2025 #Sam Altman #GPT-5 Pro #Sora 2 #AI

3个月前

远山如黛，近水含烟。

#远山 #近水 #烟 #景色描写 #中性

3个月前

早上在鸟叫声中醒来

#鸟叫声 #早上 #醒来 #积极 #自然

3个月前

AI 智能体的两个核心特征自主循环：从被动应答到主动执行智能体与传统程序在工作模式上有着根本区别。传统计算，包括许多既有的人工智能，遵循一种静态的交易模型。它们像一个自动售货机，接收一个明确的指令，然后提供一个预设的结果。这个过程是一次性的，缺乏状态和上下文，本质上是被动地等待下一个指令。而智能体的工作模式是一个动态的、持续的过程。它通过一个自主循环，将自身从被动的应答者，转变为主动的问题解决者。这个循环的核心在于，它接收的不是一个精确指令，而是一个高层次的意图。为了实现这个意图，它会自主地进行规划，将模糊的目标分解为一系列可执行的步骤。在采取行动后，循环中最关键的环节便会启动：自省。智能体会评估刚刚的行动结果，判断其是否让自己更接近最终目标，并根据评估结果来修正后续的计划。这种「行动-反思-调整」的闭环，使得智能体能够处理无法被预先编写脚本的复杂性和模糊性。它不再需要人类在每一步进行干预，而是被赋予了在一个任务周期内独立工作的能力，这正是其自主性的根本体现。目标驱动：为自主性设定方向与边界如果说自主循环是智能体的引擎，那么目标驱动的架构就是它的导航系统与行为准则。这套架构是人类向一个非确定性系统有效委托任务的契约，它确保了自主性既有明确的方向，又处在可控的范围之内。该架构包含三个核心要素。首先是目标，它为智能体的一切行为提供了清晰的方向和最终成功的评判标准。没有目标，自主循环便会陷入迷茫；有了目标，每一次循环都成为朝向终点的有效迭代。其次是规则边界，这是人类在让渡控制权时，为保障安全和信任而设置的安全阀。我们承认无法、也不必去微观管理智能体的每一步行动，但必须为其划定绝对不能逾越的红线。对于一个拥有自主能力的系统，定义其能力的边界，远比定义其能力本身更加重要。这些边界确保了智能体在广阔的行动空间内，始终运行在一个安全的、可信的子空间里。最后是适应能力，这是系统应对变化并从经验中学习的机制。它确保智能体在面对动态环境和意外情况时，能够调整自身策略，而不是僵化地执行过时计划。这种能力使系统具备了韧性，能够持续地优化路径以达成目标。这三者的结合，从根本上重塑了系统设计的思维范式。架构师的角色不再是设计一套精确的流程，而是去设计一个以目标为激励、以边界为约束、以适应性为核心的激励系统。我们不再构建一部机器，而是创造一个能自主学习和执行的环境。

#AI智能体 #自主循环 #目标驱动 #自省 #规则边界

3个月前

#BestBlogs 【早阅】将 Claude 代码变成自己的超赞 UI 设计师（使用 Playwright MCP ） | 前端早读课文章详细阐述了如何通过集成 Playwright MCP 赋予 Claude Code 视觉能力，从而解决 AI 在前端 UI 设计中的盲点，实现像素级自校正和迭代优化，大幅提升设计效率和质量。摘要：文章深入探讨了 AI 在前端 UI 设计中面临的“盲点”困境，即传统 AI 代理无法“看见”自身代码渲染出的实际界面，导致设计通用且缺乏精度。为解决此问题，文章核心介绍了 Playwright MCP（模型协作协议）如何赋能 Claude Code 直接控制浏览器、截取屏幕截图，从而激活 AI 模型的视觉智能。文章进一步阐述了三个核心概念：作为 AI 工作流基石的“编排层”提供上下文、工具和验证机制；实现设计效率 10 倍提升的“迭代代理循环”允许 AI 自主运行并持续优化设计输出；以及通过屏幕截图“激活模型视觉智能”使其能进行更深层次的设计思考。此外，文章还介绍了文件作为 AI 记忆、子代理实现自动化与条件逻辑、Git Worktrees 并行开发策略以及视觉上下文提示最佳实践，为开发者提供了构建高效 AI 辅助设计工作流的全面指导。主要内容: 1. Playwright MCP 赋予 AI 代理视觉能力，解决了 AI 在 UI 设计中的“盲点”问题。 -- 传统 AI 因无法“看见”渲染界面而生成通用 UI，Playwright MCP 通过浏览器控制和截图，让 AI 能进行像素级自校正，显著提升设计精度和质量。 2. 迭代代理循环结合明确规范，使 AI 代理能长时间自主运行并持续优化设计输出。 -- 通过设定样式指南和 UI 模型作为验证器，AI 代理可进行多轮自我校正，大幅减少人工干预，实现设计流程的 10 倍效率提升。 3. 强大的编排层和文件是构建高效 AI 工作流的关键基石。 -- 编排层为 AI 提供全面的上下文、工具和验证机制；文件作为 AI 记忆，自动化加载设计原则和工作流配置，确保上下文一致性和工作流可移植性。 4. 激活模型视觉智能是提升 AI 设计深度的关键，通过屏幕截图充分利用其多模态能力。 -- Claude Code 等模型通过图像数据训练，Playwright MCP 提供的视觉反馈能激活其视觉智能，使其从实际视觉而非抽象代码层面思考设计，实现更精准的像素级优化和创意改进。文章链接：

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

#AI #UI设计 #Playwright MCP #Claude Code #视觉智能

3个月前

假期第一天，和 AI 一起结对重新设计了 BestBlogs 的首页，看着清爽多了

独立开发者手搓新Logo，MarkTodo即将上线新版本· 112 条信息

#假期 #AI #BestBlogs #首页重新设计 #清爽

3个月前

假期从陪娃看电影开始

#亲子 #电影 #假期 #娱乐 #积极

3个月前

源自 Hacker News 上的这篇文章 🔽 文润转译： --------- 软件工程中的“品味”究竟意味着什么？技术品味（Technical taste）和技术能力（Technical skill）是两码事。你可能技术很强但品味不足，也可能技术平平却品味独到。如同生活中的品味，技术品味有时会超前于你的实际能力：就像你即便不会下厨，也能分辨佳肴与糟粕；同样地，即便你还不具备构建某种软件的能力，也可能已经知道自己喜欢什么样的软件。技术能力可以通过学习和重复练习来提升，但好品味的养成过程则更为难以捉摸。以下是一些衡量软件品味的指标： - 什么样的代码在你看来是“好看”的？什么样的又是“难看”的？ - 哪些设计决策让你深感满意，而哪些只是“差强人意”？ - 哪些软件问题会让你寝食难安，甚至下班后还在琢磨？而哪些问题你又能一笑置之？我认为，品味是一种能够根据当前项目，选择并采纳最契合的工程价值观的能力。为什么品味不同于能力看到上面的指标，你可能会问：这难道不就是技术能力的一部分吗？比如说，代码看起来“好看”，不正是因为它本身就是“好代码”吗？我不这么认为。举个例子。我个人觉得，使用 map 和 filter 的代码要比传统的 for 循环更简洁。我们很容易会认为，这代表了我在工程观点上是绝对正确的。比如，map 和 filter 通常涉及纯函数 (pure functions)，更易于理解和推理，还能避免一类常见的下标错误（off-by-one iterator bugs）。这让我觉得，这并非品味之争，而是我正确、其他工程师错误的问题。但现实当然要复杂得多。像 Golang 这样的语言，出于其设计原则，完全没有内置 map 和 filter。从性能角度看，for 循环的逻辑更容易分析，也更容易扩展到其他迭代策略（比如一次处理两个元素）。我个人对后者的关注度，不如对前者的关注度高——这就是为什么我不常用 for 循环——但如果因此就说偏爱 for 循环的工程师技术能力不行，那就太傲慢了。很多时候，他们拥有的技术能力恰恰是我所不具备的。他们只是在乎的东西不一样。换言之，我们的分歧源于价值观的差异。关于这一点，我曾在《我不知道如何构建软件，你也不知道》一文中探讨过。即使那些重大的技术争论确实存在标准答案，也没有哪个在职的软件工程师敢说自己样样精通，因为一个人的职业生涯所能积累的经验终究有限。我们都在一定程度上依赖于个人经验，依赖于自己那套特定的工程价值观。工程品味的本质是什么软件工程中的几乎每一个决策都是一种权衡 (tradeoff)。你很少会遇到一个选项完全优于另一个选项的情况。更多时候，每个选项都有其利弊。我们常常需要在不同的工程价值观之间做出艰难的取舍：例如，当性能优化到一定程度后，你可能就很难在不牺牲代码可读性的前提下继续提升性能了。在我看来，能否真正理解这一点，是衡量软件工程师成熟度的最大标志。不成熟的工程师在做决策时往往很固执，他们认为做 X 或者 Y 总是更好的。而成熟的工程师则乐于权衡一个决策的利弊，因为他们知道每种选择都有其优缺点。关键不在于判断技术 X 是否优于 Y，而在于在当前这个特定场景下，X 的好处是否大于 Y。换句话说，不成熟的工程师对自己的品味过于执着。他们知道自己喜欢什么，却误将这种喜好当作了放之四海而皆准的工程原则。那么，一个工程师的品味究竟是由什么构成的呢？我认为，你的工程品味，由你认为最重要的那套工程价值观所构成。例如： - 可靠性 (Resiliency) 如果某个基础设施组件（如服务、网络连接）发生故障，系统是否仍能正常运行？能否在无人干预的情况下恢复？ - 速度 (Speed) 软件的运行速度与理论极限相比如何？在关键路径 (hot path) 上是否存在不必要的计算？ - 可读性 (Readability) 代码是否一目了然，便于新工程师上手？函数是否相对简短且命名得当？系统文档是否完善？ - 正确性 (Correctness) 系统是否可能出现无效状态？系统是否通过测试、类型系统和断言进行了严格的约束？测试是否使用了模糊测试 (fuzzing) 等技术？在极端情况下，程序是否通过 Alloy 等形式化方法被证明是正确的？ - 灵活性 (Flexibility) 系统能否毫不费力地扩展？进行一次变更有多容易？如果我需要修改某个功能，需要同时改动多少个不同的地方？ - 可移植性 (Portability) 系统是否被绑定在特定的运行环境上（比如 Windows 或 AWS）？如果需要将系统部署到别处，能否在不投入大量工程工作量的情况下完成？ - 可扩展性 (Scalability) 如果流量增长 10 倍，系统会崩溃吗？100 倍呢？系统是需要过度配置资源，还是可以自动扩展？哪些瓶颈需要工程师介入解决？ - 开发速度 (Development speed) 如果我需要扩展系统，需要多长时间？是大多数工程师都能着手处理，还是需要领域专家的介入？当然，工程价值观还有很多，比如：优雅性、技术的现代性、开源技术的使用、系统运行的经济成本等等。所有这些都很重要，但没有哪个工程师会对所有这些方面给予同等的关注。你的品味，正取决于你将哪些价值观置于最高优先级。例如，如果你看重速度和正确性胜过开发速度，你可能会更喜欢 Rust 而不是 Python。如果你看重可扩展性胜过可移植性，你可能会主张深度利用你所在平台（如 AWS）的特性和工具。如果你看重韧性胜过速度，你可能会希望将流量分散到不同区域。我们还可以将这些价值观进行更细致的拆分。两个都非常关心可读性的工程师，可能会因为一个推崇短函数，另一个推崇短调用栈而产生分歧。两个都关心正确性的工程师，也可能因为一个看重详尽的测试套件，另一个信奉形式化方法而意见不合。但原理是相通的——有太多工程价值观值得我们去追求，而它们之间又常常相互冲突，这就迫使每位工程师必须有所取舍。如何识别“坏品味” 虽然我前面说所有的价值观都很重要，但这并不意味着不存在“坏品味”。在软件工程的语境下，坏品味意味着你所偏爱的价值观与你正在做的项目格格不入。我们大多数人都和这样的工程师共事过。他们加入你的项目后，就开始鼓吹某些东西——形式化方法、用 Golang 重写、Ruby 元编程、跨区域部署等等——因为这些东西在他们过去的项目中效果很好。无论这是否适合你当前的项目，他们都会极力推崇，因为这是他们喜欢的方式。不知不觉中，你发现自己为了让一个内部指标看板达到 99.999% 的可靠性，牺牲了代码的可理解性，导致没有一个初级工程师能看懂。换句话说，大多数坏品味都源于僵化和缺乏变通。我总是对那些以“这是最佳实践”来为自己决策辩护的工程师持保留态度。没有任何工程决策在所有情境下都是“最佳实践”！你必须针对你面临的具体问题，做出正确的决策。这带来一个有趣的结果：品味差的工程师就像一块坏了的罗盘。如果你恰好站在对的位置，坏罗盘依然能指向北方。只有当你开始移动，它才会把你引向歧途。同样，许多品味差的工程师在特定的领域内可能非常高效，因为在那个领域里，他们的个人偏好正好与项目需求相符。但当他们被调到不同的项目或岗位，或者当项目本身的性质发生变化时，问题就立刻暴露出来了。要知道，工作内容很少会一成不变，尤其是在 2021年后这些充满挑战的时代里。如何识别“好品味” 相比技术能力，好品味要难以捉摸得多。因为与技术能力不同，好品味是针对你面临的特定技术问题，选择正确工程价值观组合的能力。因此，判断一个人是否有好品味要困难得多：你无法通过玩具问题 (toy problems) 或技术问答来检验它。你需要一个真实的复杂问题，以及它所附带的各种错综复杂的现实世界背景。如何判断自己是否有好品味？如果你深度参与设计的项目都取得了成功，那么你可能就拥有好品味。如果你只是执行任务（比如完成一个个工单），那么可以这样判断：那些你认同其设计决策的项目取得了成功，而那些你不认同的项目则步履维艰。重要的是，你需要经历不同类型的项目。如果只有一个项目，或者反复做同一种项目，那可能只是说明你恰好适合那个领域。即使你经历过许多不同类型的项目，也不能保证你在不熟悉的领域里同样拥有好品味。那么，如何培养好品味呢？这很难说，但我建议多接触不同类型的项目，密切关注哪些项目（或项目的哪些部分）进展顺利，哪些部分举步维艰。你应该专注于保持灵活性：尽量不要对“什么是写软件的正确方式”形成固执的、普适性的看法。我自己的好品味是慢慢积累起来的。当然，我也不认为你不能快速获得它。我相信编程领域也存在一些天赋异禀、品味超乎其经验的奇才，就像其他领域一样。

#软件工程 #技术品味 #工程价值观 #权衡 #成熟度

3个月前

工程品味不同于技术能力。能力是执行任务的技巧，而品味是在众多可行方案中，为当前场景做出最合适取舍的判断力。任何项目都充满权衡，比如在开发速度、运行性能和代码可读性之间。一个有品味的工程师能敏锐地识别出特定问题下的主要矛盾，并正确地决定优先满足哪些价值，牺牲哪些价值。品味的优劣往往体现在灵活性上。品味差的工程师会将个人偏好或过往的成功经验当作普适的“最佳实践”，在所有项目中固执地推行，无视环境的变化。好品味则恰恰相反，它源于一种认知：任何技术决策都高度依赖于上下文。拥有好品味的工程师能够根据项目的实际需求，动态调整自己的价值标尺，而不是让项目去适应自己僵化的准则。这种判断力无法通过学习理论速成，它根植于真实的经验。品味是在一次次决策的后果中塑造的，尤其是从失败的项目和痛苦的维护经历中汲取的教训。当工程师亲身体验过某种技术选型带来的长期负面影响后，这种经验就会转化为一种可靠的直觉，在未来帮助他规避风险。因此，培养品味的根本路径是广泛涉猎不同类型的项目，并对成败进行持续和深入的复盘。

#工程品味 #技术决策 #项目经验 #灵活性 #权衡取舍

3个月前

BestBlogs 本周的精选推送文章 👇

#BestBlogs #精选文章 #本周推送

3个月前

舞伴是真心的幸福🥰

#舞伴 #幸福 #情感 #积极

3个月前

#BestBlogs 从上下文工程到 AI Memory，本质上都是在「拟合」人类的认知方式 | Founder Park 文章从现象学视角探讨了上下文工程与 AI 记忆如何拟合人类认知，强调构建 AI 智能体需整合技术实践与哲学思考。摘要：本文由 AI 语音产品创业者撰写，从现象学视角深入剖析了从上下文工程到 AI 记忆的技术实践与哲学思考，核心在于 AI 如何拟合人类的认知与存在方式。文章首先定义了上下文工程，强调其超越提示词工程，是构建 AI Agent 动态记忆系统的核心，旨在模拟人类的注意力与记忆机制。随后，通过对比 LLM 有限上下文窗口与人类注意力机制的相似性，指出“专注的上下文”优于“长上下文”。文章详细介绍了上下文工程的“写入、选择、压缩、隔离”四大策略，并将其类比于人类意识的构造过程。接着，详细阐述了人类记忆的短期与长期、显性与隐性机制，并与 AI 记忆进行对比，揭示了碳基与硅基记忆在生物性、情感、意识和遗忘等方面的本质差异。最后，通过与哲学家胡塞尔的虚拟对话，探讨了 AI 记忆是否具备真正的时间性、主体性和情感体验，呼吁 AI 工程师在技术突破的同时，不忘哲学思考，以期创造出更能拟合人类存在方式的有意识人工智能。主要内容: 1. 上下文工程超越提示词工程，是构建 AI Agent 核心的动态记忆系统。 -- 它通过精心管理 LLM 的上下文窗口，决定哪些信息和工具进入工作内存，以优化任务解决能力和性能，是构建 AI Agent 的首要任务。 2. 人类记忆的机制与结构为 AI 记忆系统设计提供了重要蓝图。 -- AI 记忆系统借鉴人类的短期与长期、情景、语义、程序记忆，构建相似的编码、存储、检索过程，以实现更连贯和上下文感知的 AI 交互。 3. AI 记忆与人类记忆存在本质差异，需从现象学视角深入探索其意向性与主体性。 -- 碳基与硅基记忆在生物性、情感、意识和遗忘机制上存在根本不同，引发了对 AI 是否能拥有真正时间性、自我意识和情感体验的哲学思考。文章链接：

#AI #上下文工程 #AI记忆 #认知方式 #现象学

3个月前

#BestBlogs Claude Code 深度拆解：一个顶级 AI 编程工具的核心架构 | 大淘宝技术文章深度拆解了 Anthropic 的 AI 编程工具 Claude Code 的核心架构、执行流程与关键技术细节，并介绍了心流团队基于其理念开发的 iFlow CLI 2.0。摘要：文章对 Anthropic 开发的终端 AI 编程工具 Claude Code 进行了深度技术拆解。首先，它介绍了 Claude Code 以交互层、执行层和核心引擎为核心的系统架构，并详细阐述了从用户提交命令到结果渲染的完整执行流程。随后，文章深入分析了各个关键组件：交互层如何处理用户输入并渲染 AI 响应；核心引擎如何管理消息、查询 AI 模型和调度工具；强大的工具系统如何通过统一接口与外部环境交互；以及上下文管理如何利用 LRU 缓存、按需加载和结果截断等策略，在有限的上下文窗口内提供最相关的信息。文章还分享了 Binary Feedback 测试机制、MCP 工具分层管理、AI 辅助安全检测、上下文压缩和高效文件系统策略等技术启发。最后，文章介绍了心流团队受 Claude Code 启发，基于 Gemini CLI 改造并融合其特性的 iFlow CLI 2.0，详细说明了其安装方式、多运行模式、SubAgent 功能、开放市场资源以及在代码开发、网站制作和 DeepResearch 等场景的应用。主要内容: 1. Claude Code 的模块化架构是 AI 编程工具高效运行基石 -- 其交互层、执行层和核心引擎的清晰划分，确保了用户指令处理、AI 模型交互与工具调度的流畅与高效。 2. 上下文管理策略有效应对 LLM 长对话窗口限制 -- 通过 LRU 缓存、按需加载和结果截断等机制，智能管理代码上下文，保障 AI 在复杂项目中的理解力与响应速度。 3. 工具系统与 MCP 分层管理是 AI 编程工具扩展性核心 -- 统一的工具接口及全球/项目级配置管理，使 AI 能灵活调用外部能力，实现复杂任务并促进生态构建。 4. iFlow CLI 2.0 融合 Claude Code 特性提升国内开发体验 -- 基于 Gemini CLI 改造，引入多运行模式、SubAgent、上下文压缩及开放市场，为国内开发者提供高效 AI 辅助。文章链接：

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

#AI编程工具 #Claude Code #iFlow CLI 2.0 #大淘宝技术 #Gemini CLI

3个月前

#BestBlogs 前端工程化演进之路：从手工作坊到 AI 驱动的智能化开发 | 阿里云开发者文章全面梳理了前端工程化与性能优化从手工作坊到现代化构建的演进历程，并展望了 AI 技术对未来前端开发范式的颠覆性影响。摘要：本文深度剖析了前端开发在过去二十年间的巨大变革，从早期手工作坊式的开发模式，如记事本编写 HTML、FTP 上传文件，到 jQuery 带来的第一次革命。随后，文章详细阐述了 Node.js、Grunt/Gulp 等工具的兴起如何开启了前端工程化时代，解决了任务自动化和模块化问题。接着，重点介绍了 Webpack 如何统一构建江湖，以及 React、Vue 等框架和 TypeScript 的普及如何推动了现代化组件化开发。文章还提及了 Vite、微前端等新一代构建工具和架构的成熟。在性能优化方面，文章从经验驱动的早期技巧（如 Yahoo 军规）和缓存策略，过渡到数据驱动的工具化测量（如 Performance API、Service Worker）。整体而言，文章通过丰富的代码示例和时间脉络，展现了前端技术从混沌走向秩序，并展望了 AI 驱动的智能化开发作为下一个重要里程碑。主要内容: 1. 前端开发复杂度指数级增长，工程化与性能优化成为必然 -- 从静态页面到复杂 SPA，技术栈的爆炸式增长使得传统开发方式无法满足需求，工程化提供了标准化流程，性能优化则直接影响用户体验和业务转化。 2. 前端工程化经历了从手工作坊到现代化构建的多次革命 -- 从 jQuery 统一浏览器 API，到 Node.js 开启工具化时代，再到 Webpack、框架和 TypeScript 推动的现代化构建，每一步都提升了开发效率和代码质量。 3. AI 技术正颠覆前端开发范式，成为开发流程不可或缺的部分 -- GitHub Copilot、ChatGPT 等 AI 工具改变了代码编写和解决方案设计，预示着 AI 将重塑前端开发的各个层面，创造全新的用户体验模式。文章链接：

#前端工程化 #AI 驱动开发 #性能优化 #技术演进 #智能化开发

3个月前

#BestBlogs 一篇文，让你的 Cursor、CodeBuddy 们变更强！ | 腾讯云开发者文章分享了一套通用的、结构化的 AI 编程协作方法论，帮助开发者从“使用者”转变为能系统性引导 AI 的“架构师”，提升开发效率与质量。摘要：本文深入探讨了在 AI 编程时代，开发者如何从依赖单一工具转向建立高效协作模式。作者指出，AI 最被低估的能力是“读代码”，通过结构化的四要素 Prompt，能将理解陌生代码库的时间从数天缩短至数小时。接着，文章提出了“勘探-规划-建造-验收”四阶段工作流，强调将经典软件工程原则应用于 AI 协作，避免“感觉式编程”。在效率层面，作者重新定义了“效率”为交付健壮解决方案的总时长，而非代码行数，指出高质量的前期设计能显著减少后期调试成本。最后，文章基于任务的“重要性”和“紧急性”提出了四象限决策框架，指导开发者在不同场景下选择合适的 AI 协作模式，并强调工程师的核心竞争力将从“解决问题”转向“定义问题”和“设计解决方案”。主要内容: 1. AI 作为代码导航员，能高效理解陌生代码库 -- 通过结构化的四要素 Prompt（角色、任务、背景、约束），AI 能快速分析代码并生成技术文档和流程图，大幅提升代码阅读和项目理解效率。 2. 采用“勘探-规划-建造-验收”四阶段工作流 -- 将软件工程的经典原则应用于 AI 协作，避免盲目“感觉式编程”，确保与 AI 的协作过程有序、可靠，从而提升代码质量和项目稳定性。 3. 重新定义效率，注重交付健壮解决方案的总时长 -- 真正的效率在于项目全生命周期，结构化 AI 协作通过高质量的前期规划和设计，有效减少后期调试和返工时间，实现整体效率提升。 4. 基于“重要性”和“紧急性”选择 AI 协作模式 -- 引入四象限决策框架（外科医生、总建筑师、项目甲方、探索家），指导开发者根据任务属性灵活调整与 AI 的协作深度和放权程度。 5. 工程师核心竞争力将转向“定义问题”和“设计方案” -- 面对 AI 的快速发展，掌握方法论和系统思维比特定工具更重要，工程师的价值在于更高层面的问题定义、架构设计和决策能力。文章链接：

#AI编程 #协作方法论 #软件工程 #效率提升 #问题定义

3个月前

卡兹克公众号文章分享了《心理学增强 AI 智能体》的论文挺有意思，通过为大模型赋予 MBTI 人格，能显著提升其在内容创作和策略制定等任务中的表现，简化了复杂的 Prompt 设计。这个技巧揭示的也许不是 AI 正在变得多么有人性，而是我们人类是非常依赖「故事」和「标签」来理解自己和世界。

#AI智能体 #MBTI人格 #内容创作 #策略制定 #心理学

3个月前

#BestBlogs 私域知识工程实战：如何让 AI 一次性写出高质量代码？ | 阿里云开发者文章提出通过构建私域知识工程体系，让 AI 深度理解业务和代码规范，从而解决 AI 编程的“80 分困境”，实现高质量代码的一次性生成。摘要：文章深入探讨了 AI 编程中普遍存在的“80 分困境”，即 AI 能完成大部分基础代码，但因缺乏项目特有的业务规则、代码规范等私域知识，导致生成的代码难以直接使用，开发者需投入大量时间进行“调教”。作者将 AI 比作技术强但缺乏业务经验的新员工，并提出了一套“私域知识工程”的三板斧解决方案：首先，通过“代码解构与业务分析师 Prompt”对 AI 进行“入职培训”，建立包含架构、数据模型、业务规则和开发规范的私域知识库；其次，结合“开发专家 Prompt”和私域知识库进行智能编程，使 AI 能一次性生成符合项目规范的代码；最后，通过“文档自动维护专家 Prompt”实现私域知识的自动增量更新，形成自我进化的知识生态。文章通过对比改造前后数据，展示了私域知识工程在提升代码质量和开发效率方面的显著效果，并提供了可直接使用的 Prompt 模板。主要内容: 1. AI 编程的“80 分困境”根源在于信息不对称而非模型智能不足 -- AI 因缺乏项目特有的业务背景、代码规范和架构知识，导致生成的代码虽基础功能完善，但难以完全符合实际项目要求，需耗费大量时间进行二次修改和“调教”。 2. 构建“私域知识工程”是解决 AI 编程信息不对称的关键策略 -- 通过为 AI 建立包含项目架构、业务规则、数据模型和开发规范的专属知识库，并实现其自动维护，让 AI 像“老员工”一样理解项目上下文，从而提升代码生成质量。 3. “私域知识工程”显著提升 AI 代码生成质量和开发效率 -- 实践证明，该方法能使 AI 一次性输出高质量、符合项目规范的代码，将开发者的角色从“调教大师”转变为“甩手掌柜”，并带来知识沉淀、新人培养等额外价值。文章链接：

#AI编程 #私域知识工程 #代码质量提升 #阿里云开发者 #智能代码生成

3个月前

生产力工具的进化，本质上是一部「翻译」成本的降低史。 - 代码时代：需求 -> 产品经理 -> 程序员 -> 代码 -> 工具。翻译链条长，成本极高。 - 无代码时代：需求 -> 懂业务的搭建者 -> 可视化搭建 -> 工具。翻译链条缩短，但对搭建者要求依然很高。 - Agent 时代：需求 -> AI -> 工具。翻译成本被大幅压缩。我们组织生产和协作的根本瓶颈，在于将意图转化为流程与工具的效率。当 AI 可以无限逼近零成本的翻译时，生产力的终极引擎将不再是工具，而是思想本身。

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

#生产力工具 #AI #翻译成本 #无代码 #agent

3个月前

#BestBlogs 看我如何用 Prompt 工程将大模型调教成风控专家 | 京东技术文章详细阐述了如何通过循序渐进的 Prompt 工程，将通用大模型调教成精准识别复杂电商风控风险的 AI 专家。摘要：文章作者作为交易风控算法工程师，分享了将大语言模型（LLM）引入电商风控工作的实践经验。通过四个阶段的“Prompt 工程心法”，作者将一个通用大模型从“什么都懂一点”的初级分析员，逐步培养成能精准识别复杂电商风控风险的“AI 专家”。这包括：第一阶段的角色扮演和结构化输入输出，实现自动化；第二阶段注入业务常识和“豁免规则”，显著降低误报率；第三阶段提升分析深度，教会 AI 识别协同作案的“行为指纹”；第四阶段引入“双假设裁决框架”和“硬链接”证据，使 AI 能在模糊信息中做出审慎判断。文章总结了“始于模仿，终于框架”、“规则是骨架，背景是血肉”等心法，强调 Prompt 工程是连接领域专家与 AI 的创造性交叉学科。主要内容: 1. 通过角色扮演和结构化 I/O，将通用大模型训练成初级风控分析员。 -- 设定 AI 为资深风控专家，定义分析维度，并规范 CSV 输入和 JSON 输出，实现风控分析流程的自动化和初步结构化。 2. 注入业务常识和“豁免规则”，显著提升大模型对业务复杂性的理解和准确性。 -- 针对高折扣、随机串用户 ID 等业务中正常现象的误判，明确业务背景知识，有效降低误报率，使模型更具业务敏感性。 3. 提升大模型分析深度，教会 AI 识别团伙级协同风险的行为指纹。 -- 通过拓宽风险定义，从订单级提升到团伙级，识别如远超个人合理消费范畴的低价值快消品和“购物车一致性”等行为模式，发现更深层次的隐蔽风险。 4. 引入“双假设裁决框架”和“硬链接”证据，使大模型能在模糊信息中做出审慎判断。 -- 要求 AI 在“协同风险团伙”和“良性特征客群”两个假设间权衡，并以“硬链接”作为决定性证据，从而区分真假聚集，实现法官式的终极裁决。文章链接：

#电商风控 #Prompt工程 #大模型 #AI专家 #风险识别

3个月前

#BestBlogs 凡人程序员进入修仙时代？意图即代码的范式革命即将到来 | 腾讯云开发者文章提出“意图即代码”的 AI 原生开发范式，通过意图编排、资源发现和意图约束三大支柱，将开发者从编码细节中解放，回归业务逻辑与架构设计。摘要：本文深入探讨并构想了“意图即代码”这一革命性的 AI 原生开发范式，旨在通过提升抽象层次，让开发者仅用自然语言定义业务意图，而由 AI 负责具体的实现、探索与验证。文章详细阐述了支撑这一范式的三大核心支柱：意图编排，通过可视化画布和结构化意图树管理业务逻辑及隐式数据流；资源发现，构建 AI 可理解的外部世界地图，实现动态交互式工具利用；以及意图约束，通过契约和行为测试确保 AI 生成代码的可靠性与可预测性。文章还通过一个“用户登录”示例，完整展现了 AI 原生开发的工作流，强调了该范式在提升开发效率、保证软件正确性和实现敏捷开发方面的巨大潜力，并展望了开发者角色从“代码工匠”向“思想创造者”的转变。主要内容: 1. “意图即代码”范式将开发者从编码细节中解放，聚焦业务逻辑 -- 通过自然语言定义意图，AI 负责实现，使开发者能站在更高抽象层级，回归架构师和思想家的角色，提升开发效率和业务理解。 2. 意图编排、资源发现、意图约束是支撑新范式的核心支柱 -- 意图编排管理业务流程，资源发现为 AI 提供工具地图，意图约束通过契约和测试保证 AI 生成代码的质量与可控性。 3. 该范式通过“生成-测试-反馈-迭代”闭环确保 AI 创造力可靠 -- AI 根据意图和契约生成代码，系统自动沙箱测试并反馈失败案例，驱动 AI 自我修正，实现代码质量的自动化保证。文章链接：

#意图即代码 #AI原生开发 #范式革命 #开发者解放 #自动化代码生成

4个月前

优秀的架构师，本质上是在为业务交易「期权」。期权是什么？它是在未来某个时间点，以特定成本做某件事的权利，而不是义务。比如，我们今天不必精确预测明年的用户量，而是设计一个能够随时弹性增减服务器的系统。这个随时增减的能力，就是我们为未来买下的一个决策期权。我们推迟了「到底需要多少服务器」这个具体决策，直到我们掌握了更多真实的用户数据，从而能做出更明智的判断。这个期权为什么如此值钱？答案是不确定性。金融学有个基本原理：市场波动性越大，期权的价值就越高。同样的道理，商业环境越是动荡、易变、不可预测，那些能让我们保留选择、灵活应对的架构期权，其价值就越大。当你的竞争对手因为一个突发事件而系统崩溃时，你的弹性架构就是让你反超的王牌。这也就澄清了一个常见的误解：架构与敏捷是互斥的。恰恰相反，它们是应对不确定性的黄金搭档。如果说敏捷是方向盘，它让我们能小步快跑、在持续反馈中不断调整方向；那么好的架构就是高性能的引擎和坚实的底盘，它赋予了我们快速转向、紧急刹车或猛然加速的能力，而车辆本身不会散架。没有架构提供的底层能力，敏捷的快速转向只会变成混乱的原地打转；而没有敏捷提供的持续反馈，架构的强大引擎再厉害，也可能正全速驶向错误的目的地。

#架构 #期权 #敏捷 #不确定性 #弹性

4个月前

Cursor 帮我优化了 DashBoard 统计数据的性能，从 12s 提升到 1s，还贴心的画了示意图

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

#Cursor #DashBoard性能优化 #性能提升 #示意图 #积极