AI编程
-
AI编程助手频繁“断片”?Cursor、Lovable、Bolt长项目中断问题的工程解法
在使用 Cursor、Lovable、Bolt.new 等 AI 编程智能体时,连续对话约 15 到 20 轮后,模型可能开始遗忘边界条件、破坏已有逻辑,甚至虚构数据结构。本文围绕长项目中的上下文衰减问题,整理结构化 PRD、任务拆分、检查点和工作流编排等工程方法。
-
AI 写 Python 代码时最容易埋下的一个安全隐患:SQL 注入
AI 生成的 Python 代码经常使用 f-string 拼接 SQL,这种写法可读性强,却容易带来 SQL 注入风险。开发者需要在代码审查、IDE 插件和自动化检测环节建立防线。
-
T3 Code:把多个 AI 编程 Agent 放进同一个控制台
T3 Code 是一个开源的 AI 编程 Agent 控制台,可将 Claude Code、Codex、OpenCode、Cursor 和 Grok Build 等工具放入统一控制平面,并支持手机、浏览器和桌面远程调度。
-
AI 编程助手留下的代码,谁来负责?一套可写进团队 Wiki 的治理 SOP
AI 编程助手降低了代码生成成本,但没有降低维护成本。团队真正需要的,是一套写进 Wiki 的 SOP:谁审核、谁归档、谁负责、谁承担风险。
-
AI 重构旧组件,不能从“帮我重写”开始
AI 可以快速重写一个旧 React 组件,但真正的风险在于隐藏依赖、失效假设和模糊边界。本文以一场面试案例为线索,整理出画依赖图、识别隐藏假设、按副作用拆分、给 AI 可验证指令的重构方法。
-
单个 Agent 不够用的时候:拆解 MyCodeAgent 中多 Agent 团队协作的设计与退场
MyCodeAgent 曾推出实验性多 Agent 协作系统 AgentTeams,尝试通过团队创建、任务分发、结果收集和协调者合并,让多个 Agent 并行处理代码重构、测试等复杂任务。该机制最终被移除,但其设计揭示了 AI 编程工具在处理大型工程任务时必须面对的任务分解、上下文隔离和状态同步问题。
-
OpenJDK 禁止 AI 代码五个月后:规则还在,执行只能靠提交者自觉
OpenJDK 临时 AI 政策实施近五个月后,禁令仍然有效,但由于无法可靠区分人类代码与 AI 代码,最终只能依靠提交者勾选确认和社区自觉。与此同时,Debian 选择允许负责任使用生成式 AI,却引发核心开发者离开;同一母公司旗下的 GraalVM 则采取“提交者负全责”的宽松路线。开源社区在 AI 代码治理上仍未找到统一答案。
-
从「一只虾」到「多只虾」:一次 AI 助手拆分实践背后的协作逻辑
当 AI 助手承载的技能、记忆和任务越来越多,单一模型架构开始暴露出上下文对齐、技能加载和能力适配等问题。一次从“一只虾”到“多只虾”的拆分实践,为理解多 Agent 协作提供了具体样本。
-
不靠 LangChain 手撸一套 RAG,才能真正看懂检索增强生成
calmrocks/ai-engineer-notebooks 提供了一组可在 Colab 中运行的实战 Notebook,绕开 LangChain 等框架,直接用原始 API 搭建 Prompt 工程、RAG、Agent 和评测流程。对于想理解 RAG 底层链路的开发者来说,这类练习的意义不只是学会调用接口,而是把检索、重排、生成和评测重新拆开检查。
-
Claude Code 打通终端与桌面会话:AI 编程助手开始补上“工作连续性”短板
Anthropic 为 Claude Code 桌面端新增 /resume 功能,可恢复 CLI 终端中的历史会话。AI 编程助手正从单轮聊天工具,走向更重视上下文连续性的开发工作流工具。