__init__.py 是个啥，为什么深受大厂程序员偏爱？

👋 朋友们，今天我们来聊聊 Python 里一个低调却至关重要的文件 ——`__init__.py`。 说实话，这玩意儿刚开始学 Python 时，很多人（包括当年的我）都是一脸懵：“这啥？删了会咋样？” 有些人可能听说过它是 “包的标志”，也有人觉得它 “没啥大用，可以忽略”，更有甚者以为它 “只是个装样子的文件”😂。今天，我们就来彻底搞清楚 `__init__.py` 到底是干啥的，以及它如何影响 Python 项目的结构和运行。 🏗️ 先搞懂 Python 模块（module） 在聊 `__init__.py` 之前，我们得先弄清楚 Python 里的 ** 模块 ** 和 ** 包 ** 这两个概念。 📌 ** 模块（module）** ：简单来说，就是一个 `.py` 文件，里面写了一些函数、类或者变量。 比如，有个叫 `math_tools.py` 的文件，里面有一堆数学工具函数，那它就是个模块。 **# math_tools.py** def add(a, b): return a + b def subtract(a, b): return a - b 然后，我们可以在别的 Python 文件里这样用它： import math_tools print(math_tools.add(3, 5)) # 输出 8 这就是 ** 模块的基本用法 **，没啥难的，对吧？ 📦 Python 包（package）是啥？ 如果你写的模块越来越多，代码量越来越大，就得想办法组织它们。这时候，Python 里的 ** 包（package）** 就派上用场了。 📌 ** 包（package）** ：一个 ** 文件夹 **，里面包含多个模块（`.py` 文件）。 在 **Python 3.3 之前 **，如果要让一个目录被识别为 Python 包，必须在里面创建 `__init__.py` 文件。** 但从 Python 3.3 开始，即使没有 `__init__.py`，Python 也能识别它是一个包（称为 “命名空间包”）。** 不过，大部分实际项目 ** 依然建议添加 `__init__.py`**，因为它可以： ✅ 明确这个文件夹是一个包，避免某些工具（如打包工具）识别错误。 ✅ 允许在包初始化时执行特定代码，比如自动导入子模块。 ✅ 让导入行为更加可控，避免意外的命名冲突。 比如，咱们有个 `math_utils` 目录，里面放了几个数学相关的模块： math_utils/ # 这个文件夹就是一个包 │── __init__.py │── basic.py │── advanced.py 其中，`basic.py` 和 `advanced.py` 分别是两个模块，而 `__init__.py` 可以用来 ** 自定义包的导入行为 **。 顺便吆喝一声，技术大厂，前后端、测试 [捞人] 捞人]，待遇还不错～ 🎭 那么 `__init__.py` 到底是干嘛的？ 虽然 `__init__.py` 不再是创建包的 ** 必需 ** 条件，但它依然是 Python 项目里一个重要的组件。 它的主要作用有 ** 两个 **： 1️⃣ 明确标记目录为 Python 包 如果 `__init__.py` 存在，Python 解析器就会知道： **“这个目录是个 Python 包，而不是普通文件夹。”** 即使 Python 3.3+ 之后不强制要求 `__init__.py`，但加上它可以： ✅ 避免 Python 解释器在某些情况下误认为这是普通目录。 ✅ 兼容旧版本 Python，让代码能在不同环境中运行得更稳定。 ✅ 让某些工具（如 `pytest`、`mypy`）更好地识别项目结构。 2️⃣ 让包能像模块一样被导入 如果 `__init__.py` 里什么都不写，那它的作用只是个 “标志”。但如果我们在 `__init__.py` 里加点代码，它就能 ** 自定义包的导入行为 **。 🌟 ** 示例 1：让包直接暴露子模块 ** **# math_utils/__init__.py** from .basic import add, subtract from .advanced import power 这样，我们就可以直接 import 整个 `math_utils`，而不需要写 `.basic` 或 `.advanced` 了： import math_utils print(math_utils.add(2, 3)) # 输出 5 print(math_utils.power(2, 3)) # 假设 advanced 里有个 power 函数 等于说，`__init__.py` 让 ** 包变得像一个大模块 ** 一样，外部不需要知道里面的模块结构，直接用就行。 🌟示例 2：包初始化操作 `__init__.py` 还能在包被导入时执行一些初始化操作，比如加载配置、设置日志等： **# math_utils/__init__.py** print("数学工具包加载成功！") # 只要 import 这个包，就会执行这行代码 🔥 `__init__.py` 还能干点啥？ 大厂的 Python 项目里，`__init__.py` 还经常被用来做这些事： ✅ 1. ** 动态导入子模块 ** 在大型 Python 项目中，随着模块越来越多，手动维护 `__init__.py` 将变得特别复杂还容易出错，这时候动态导入子模块就成了香饽饽了。 假设我们不知道 `math_utils` 里具体有哪些模块，可以让 `__init__.py` 在导入时动态扫描并加载： **# math_utils/__init__.py** import os import importlib **# 获取当前包的路径** package_path = os.path.dirname(__file__) **# 遍历当前目录下的所有 .py 文件（不包括 __init__.py 本身）** for module in os.listdir(package_path): if module.endswith(".py") and module != "__init__.py": module_name = module[:-3] # 去掉 .py 后缀 importlib.import_module(f"{__name__}.{module_name}") # 动态导入模块 ✨ 效果：** 这样，当你在别的地方写 `import mypackage`，所有 `mypackage` 里的 `.py` 文件都会自动加载，不用再手动 `import` 了！🎉 ✨没加动态导入要这么写：** import math_utils.basic print(math_utils.basic.add(1,2)) #如果直接 import math_utils 会报错AttributeError: module 'math_utils' has no attribute 'basic' **✨加了动态导入可以这么写：** import math_utils print(math_utils.basic.add(1,2)) ✅ 2. ** 控制对外暴露的模块 ** 有时候，我们不想让 ** 所有 ** 子模块都被自动导入，而是只暴露一部分给外部用。这时候可以用 `__all__` 来 ** 手动控制 ** 允许被 `from mypackage import *` 访问的模块。 **# math_utils/__init__.py** import os import importlib package_path = os.path.dirname(__file__) __all__ = [] for module in os.listdir(package_path): if module.endswith(".py") and module != "__init__.py": module_name = module[:-3] __all__.append(module_name) # 只暴露在 __all__ 里的模块 importlib.import_module(f"{__name__}.{module_name}") 🌟 ** 效果 **： from math_utils import * print(basic) # 只有在 __all__ 里的模块能被导入 ✅ **3. 懒加载（Lazy Import） 如果某些模块比较大，加载它们会影响性能，那可以用 ** 懒加载 **（lazy import）技术，在需要时才导入，而不是在 `import mypackage` 时一次性全加载。 **# math_utils/__init__.py** import importlib def lazy_import(name): return importlib.import_module(f"{__name__}.{name}") module1 = lazy_import("basic") 🌟 ** 效果 **： 这样，`basic` 只有在第一次被使用时才会真正导入，提高了性能！💡 ✅ 4. ** 做版本控制 ** `__init__.py` 还能给包加上版本号，让外部代码可以访问： **# math_utils/__init__.py** __version__ = "1.0.0" 然后，在别的地方可以这样用： import math_utils print(math_utils.__version__) # 输出 "1.0.0" ✅ 5. ** 隐藏内部实现 ** 有些模块是 “内部用” 的，不想让外部访问，怎么办？可以在 `__init__.py` 里手动控制 ** 对外暴露的内容 **： **# math_utils/__init__.py** from .basic import add, subtract __all__ = ["add", "subtract"] # advanced.py 里的东西就不会被直接 import 这样，外部只能用 `math_utils.add ()`，但 `math_utils.advanced` 就不让直接访问了。 🎉 结尾 关于 `__init__.py`，咱们就聊到这儿！希望这篇文章能帮你彻底搞懂它的作用，今后写 Python 项目时能更自信地使用它。 —— 转载自：花小姐的春天

Agent 不是多角色聊天，而是让大模型在边界内完成任务

Agent 这个词现在被用得很乱。有人把它理解成“会自己思考的 AI”，有人把它理解成“多个角色互相讨论”，也有人认为只要给大模型接几个工具，就已经是在做 Agent。 但从工程角度看，Agent 最重要的不是“看起来多自主”，而是： **它能不能在明确边界内，稳定完成一个多步骤任务。** 这才更接近真实 AI 应用开发。  ## 一、普通大模型调用解决的是“回答”，Agent 解决的是“任务” 普通 LLM 调用一般是这样的： 用户输入一个问题，模型返回一段文本。 比如用户问： > 帮我写一段求职信。 模型直接生成一段求职信。 这个过程没有问题，但它本质上还是一次文本生成。模型并不知道用户的真实简历细节有没有支撑这段求职信，也不知道目标 JD 的关键要求是什么，更不知道哪些内容不能夸大。 RAG 往前走了一步：它会先检索知识库、文档或数据库，再让模型基于材料回答。它主要解决的是“回答有没有依据”。 但 Agent 要解决的不是单次回答，而是任务推进。它不只是“查资料再回答”，而是要根据任务目标，在多个步骤之间做选择： - 它可能需要先判断用户意图，再决定要不要查询订单； - 它可能需要先检索售后政策，再判断是否能退款； - 它可能需要生成一个草稿，但不能直接提交； - 它可能需要发现证据不足，然后暂停，要求用户补充信息。 也就是说，Agent 面向的不是单次回答，而是一个可执行的任务过程。 所以我更愿意把 Agent 看成一个系统问题： **Agent 不是把 prompt 写得更像人，而是把模型放进一个可以行动、可以观察、可以被约束的系统里。** ## 二、Agent 和 Workflow 的区别 我不太建议一上来就从“自主规划”理解 Agent。 Anthropic 在《Building effective agents》里把 agentic systems 分成 workflow 和 agent。Workflow 是 LLM 和工具按照预设代码路径被编排；Agent 则是 LLM 可以动态决定自己的流程和工具使用方式。它们都属于 agentic system，但工程含义不同。 这个区分很重要。 如果你的任务路径本来就很清楚，比如： 1. 解析 JD 2. 解析简历 3. 匹配能力项 4. 找出缺口 5. 生成定制简历 6. 做证据检查 7. 输出风险提示 那它更适合先做成 workflow，而不是一上来就交给 Agent 自己规划。 Workflow 的好处是可控、可测、可复盘。 Agent 的价值在于处理那些路径不固定、步骤数量不确定、需要根据中间结果不断调整的任务。 比如客服场景里，用户可能问的是物流、退款、发票、商品参数、投诉、优惠券、售后政策，也可能把多个问题混在一起。系统很难提前写死所有路径，这时 Agent 才有更明确的价值。 换成代码视角，区别更明显： **Workflow 的下一步主要由开发者写死。 Agent 的下一步主要由模型根据当前状态决定。** 这不是说 Agent 没有代码控制，而是说代码负责提供工具、状态和边界，模型负责在这些边界里选择下一步。 但这不代表 Agent 可以无限自由。恰恰相反，Agent 越能行动，越需要边界。 ## 三、用代码理解 Agent 从代码角度看，Agent 不是一个神秘概念。 它可以先理解成： **Agent = 一个由 LLM 驱动下一步决策的任务循环。** 这里的“循环”不是说所有框架源码都必须写成 while，而是说 Agent 的运行语义大致相同：模型决定下一步，应用执行工具，工具结果写回状态，模型再基于新状态继续判断。 ```java while (!state.isFinished()) { AgentDecision decision = llm.decideNextStep(state, availableTools); if (decision.isFinalAnswer()) { return decision.answer(); } if (decision.isToolCall()) { policyGate.check(user, decision.toolName(), decision.arguments()); ToolResult result = toolExecutor.execute( decision.toolName(), decision.arguments() ); state.addToolResult(result); traceLog.record(decision, result); } if (decision.needHumanApproval()) { return pauseForHumanReview(state); } } ``` 这不是某个 Agent 框架的完整源码，而是 Agent 的核心运行语义。 普通 LLM 是： ```java String answer = llm.chat(userQuestion); return answer; ``` RAG 是： ```java List<Document> docs = retriever.search(userQuestion); String answer = llm.chat(userQuestion, docs); return answer; ``` Workflow 是： ```java JdInfo jd = parseJd(input); ResumeInfo resume = parseResume(input); MatchResult match = matchResumeToJd(jd, resume); RewriteResult rewrite = rewriteResume(match); RiskReport risk = checkEvidence(rewrite); return result; ``` Agent 是： ```java AgentState state = new AgentState(userGoal); while (state.canContinue()) { AgentDecision decision = model.decide(state, tools); switch (decision.type()) { case CALL_TOOL -> { ToolResult result = executeTool(decision); state.observe(result); } case ASK_USER -> { return askUserForMoreInfo(decision.question()); } case NEED_APPROVAL -> { return waitForHumanApproval(decision.action()); } case FINAL -> { return decision.finalAnswer(); } } } ``` 区别就在这里： **Workflow 的下一步是代码写死的。 Agent 的下一步是模型根据当前状态决定的。** 这也对应了 Anthropic 对 workflow 和 agent 的区分：前者按预设路径执行，后者由模型动态决定流程和工具使用。 --- ### 代码上，一个 Agent 至少有 5 个对象 不要先想 LangGraph、CrewAI、AutoGen。先想这 5 个类。 #### （1）AgentState：任务状态 ```java public class AgentState { private String goal; private int step; private List<Message> messages; private List<ToolCallRecord> toolCalls; private Map<String, Object> facts; private boolean finished; private boolean needHumanApproval; } ``` 它回答一个问题： **任务现在进行到哪一步了？** 没有 `AgentState`，就不是连续任务，只是一次问答。 --- #### （2）AgentTool：工具 ```java public interface AgentTool { String name(); String description(); ToolResult execute(Map<String, Object> arguments); } ``` 比如电商客服 Agent 里可以有： ```java public class GetOrderTool implements AgentTool { public String name() { return "get_order"; } public String description() { return "根据 orderId 查询当前用户的订单状态"; } public ToolResult execute(Map<String, Object> args) { String orderId = (String) args.get("orderId"); // 查数据库 / 调接口 return orderService.getOrder(orderId); } } ``` Spring AI 的 Tool Calling 也是类似思想：模型提出工具调用请求，应用程序负责解析、执行工具、再把结果返回给模型。模型不是直接操作你的数据库。 --- #### （3）AgentDecision：模型决定下一步 ```java public sealed interface AgentDecision permits CallTool, FinalAnswer, NeedHumanApproval { } public record CallTool( String toolName, Map<String, Object> arguments ) implements AgentDecision { } public record FinalAnswer( String answer ) implements AgentDecision { } public record NeedHumanApproval( String action, String reason ) implements AgentDecision { } ``` 这里就是 Agent 和普通程序最大的区别。 普通程序是你写： ``` 先查订单，再查政策，再生成回复。 ``` Agent 是模型返回： ``` { "type": "CALL_TOOL", "toolName": "get_order", "arguments": { "orderId": "123456" } } ``` 然后你的后端决定： - 这个工具存不存在？ - 这个用户有没有权限？ - 这个 orderId 是不是他的？ - 这个动作需不需要人工确认？ --- #### （4）PolicyGate：权限边界 ```java public class PolicyGate { public void check(User user, String toolName, Map<String, Object> args) { if (toolName.equals("submit_refund")) { throw new NeedHumanApprovalException("退款提交必须人工确认"); } if (toolName.equals("get_order")) { String orderId = (String) args.get("orderId"); if (!orderService.belongsToUser(orderId, user.id())) { throw new AccessDeniedException("不能查询他人订单"); } } } } ``` 边界不是 prompt 里写一句“不要越权”，而是代码里真的拦住。 OWASP 的 Excessive Agency 风险，本质就是 LLM 系统被授予过多功能、权限或自主性后，可能造成破坏性动作；所以工具权限、人工确认、最小授权必须在系统层实现。 --- #### （5）AgentRunner：核心循环 ```java public class AgentRunner { private final LlmClient llm; private final ToolRegistry toolRegistry; private final ToolExecutor toolExecutor; private final PolicyGate policyGate; private final TraceLog traceLog; public AgentResult run(User user, String goal) { AgentState state = new AgentState(goal); while (!state.isFinished() && state.getStep() < 10) { AgentDecision decision = llm.decideNextStep(state, toolRegistry.availableTools()); if (decision instanceof FinalAnswer finalAnswer) { state.finish(); return AgentResult.success(finalAnswer.answer()); } if (decision instanceof NeedHumanApproval approval) { return AgentResult.waitingForApproval(approval.action(), approval.reason()); } if (decision instanceof CallTool callTool) { policyGate.check(user, callTool.toolName(), callTool.arguments()); ToolResult result = toolExecutor.execute( callTool.toolName(), callTool.arguments() ); state.addToolCall(callTool, result); traceLog.record(state, callTool, result); state.nextStep(); } } return AgentResult.failed("Agent stopped: max steps reached."); } } ``` OpenAI Agents SDK 里所谓 agent loop，本质也是：处理工具调用，把结果送回 LLM，然后继续运行直到任务完成；同时配套 guardrails、sessions、tracing 等工程能力。 --- ### 用电商客服理解一次完整执行 用户问： > 我的订单签收三天了，商品破损，可以退吗？ Agent 第一次判断： ```json { "type": "CALL_TOOL", "toolName": "get_order", "arguments": { "orderId": "A1001" } } ``` 后端执行： ```java policyGate.check(user, "get_order", args); ToolResult order = getOrderTool.execute(args); state.addToolResult(order); ``` 工具返回： ```json { "orderId": "A1001", "status": "SIGNED", "signedDaysAgo": 3, "productCategory": "electronics" } ``` Agent 第二次判断： ```json { "type": "CALL_TOOL", "toolName": "get_refund_policy", "arguments": { "category": "electronics" } } ``` 工具返回： ```json { "category": "electronics", "returnWindowDays": 7, "needDamagePhoto": true, "autoRefundAllowed": false } ``` Agent 第三次判断： ```json { "type": "FINAL", "answer": "你的订单签收 3 天，仍在 7 天售后窗口内。但商品破损需要上传图片凭证，我可以先帮你生成退款申请说明，提交退款前需要你确认。" } ``` 这就是一个最小 Agent 的运行过程。 它不是一次性回答，而是： ```text 看当前状态 → 决定查订单 → 得到订单结果 → 决定查政策 → 得到政策结果 → 判断不能直接退款 → 给出受边界约束的答案 ``` 所以，从代码视角看，Agent 不是让模型直接控制系统，而是让模型提出下一步动作，再由应用程序判断、执行、记录和约束。 ## 四、Agent 的核心不是“自主”，而是工具、状态和边界 一个更工程化的 Agent 定义可以是： **Agent = LLM + Tools + State + Control Loop + Guardrails** 拆开看： - LLM 负责理解任务和选择下一步。 - Tools 负责连接数据库、订单系统、知识库、搜索服务等外部能力。 - State 负责记录任务进展、工具调用历史和中间结果。 - Control Loop 负责把模型决策、工具执行和结果反馈串起来。 - Guardrails 负责限制模型不能越权、不能乱调用工具、不能直接执行高风险动作。 这里最容易被忽略的是工具调用的安全边界。 Spring AI 官方文档对 tool calling 的说明很清楚：虽然通常说 tool calling 是模型能力，但实际执行工具调用逻辑的是客户端应用。模型只能请求工具调用并提供参数，真正执行工具、返回结果的是应用程序本身；模型并不会直接获得工具背后的 API 权限。 这句话非常关键。 因为它说明 Agent 不是让模型直接控制系统，而是让模型提出行动意图，再由应用层判断是否执行。 比如电商客服 Agent 面对“我的订单能退吗？”这个问题时，它不应该直接回答“可以退”。 更合理的方式是：先查询订单，再查询售后政策，再结合订单状态、商品类目和平台规则生成回复。如果涉及退款提交，就只能生成草稿，不能直接执行。 这才是可上线的 Agent。 ## 五、Agent 的真正风险：从“回答错误”变成“行动越界” 普通大模型回答错，风险主要在内容层。 Agent 一旦接入工具，风险就进入系统层。 它可能查错数据，调用错工具，传错参数，泄露敏感信息，执行不该执行的操作，或者在错误前提下连续行动。 OWASP LLM Top 10 里专门列出了 Prompt Injection、Insecure Plugin Design、Excessive Agency 等风险。其中 Excessive Agency 指的是给 LLM 过多、未受约束的行动自主权，可能破坏可靠性、隐私和信任。 这也是为什么我不赞成一开始就做“全自动 Agent”。Agent 安全不能只靠 prompt，而必须靠工具权限、参数校验、人工确认和审计日志这些系统层设计。 真正的工程顺序应该是： - 先让模型会读。 - 再让模型会查。 - 再让模型会生成草稿。 - 再让模型在低风险场景自动执行。 - 最后才考虑高风险动作的半自动化或自动化。 对于工具权限，我更倾向于分四层： **READ：只读查询，可以自动执行。** 例如查询订单状态、查询物流、检索政策文档。 **DRAFT：只生成草稿，不真正提交。** 例如生成退款说明、工单回复、邮件草稿。 **WRITE_REVIEW：会改变系统状态，必须人工确认。** 例如提交退款申请、修改用户资料、发送正式邮件。 **DANGEROUS：默认禁止。** 例如删除数据、批量修改权限、执行任意命令。 如果一个 Agent 系统没有这个权限分层，那它本质上还不能算生产级 Agent，只是一个接了工具的聊天机器人。 ## 六、一个更接近真实项目的 Agent 示例 假设我们要做一个跨境电商客服 Agent。 用户问： > 我这个订单已经签收三天了，商品有破损，能不能退？ 一个不可靠的 AI 可能会直接回答： > 一般情况下，签收七天内可以退货。 这句话听起来合理，但它不一定正确。 因为真实判断至少需要几个条件： - 订单是否真实存在？ - 订单是不是当前用户的？ - 商品类目是什么？ - 是否支持无理由退货？ - 破损是否需要上传凭证？ - 当前是否超过售后时间？ - 平台政策和商家政策是否冲突？ - 是否需要人工客服介入？ 所以更合理的 Agent 流程应该是： ```text 用户问题 → 意图识别：售后 / 退款 / 商品破损 → 查询订单状态 → 检索售后政策（RAG 在这里是证据工具） → 检查商品类目 → 判断是否需要图片凭证 → 生成客服回复 → 标注证据来源 → 如果涉及退款提交，进入人工确认 → 记录整次 Agent Run ``` 在这个流程里，模型不是凭常识回答，而是在工具和证据的约束下完成任务。 这就是 Agent 相比普通聊天机器人的真正区别：它不是凭常识直接回答，而是在工具、证据和权限边界内推进任务。 ## 七、为什么不要一开始做多 Agent 很多 Agent 教程喜欢从多 Agent 开始： 一个产品经理 Agent，一个架构师 Agent，一个开发者 Agent，一个测试 Agent，大家互相讨论，最后输出结果。 这种演示很容易吸引眼球，但工程价值未必高。 多数真实业务问题，不是靠“多几个角色说话”解决的，而是靠更清楚的任务边界、更可靠的工具、更稳定的状态记录和更严格的输出校验解决的。 多 Agent 只有在这些场景下才更有必要： - 不同角色确实需要不同职责； - 不同 Agent 拥有不同工具权限； - 需要一个 Agent 审查另一个 Agent 的输出； - 任务路径复杂到单一 workflow 难以维护； - 系统需要长期运行和异步协作。 否则，多 Agent 很可能只是增加延迟、成本和调试难度。 所以第一篇不应该从多 Agent 开始，而应该先讲清楚单个 Agent 如何完成任务、如何调用工具、如何记录状态、如何控制边界。 ## 八、我对 Agent 的第一性原则 如果让我用一句话定义 Agent，我不会说它是“自主智能体”。 我更愿意说： **Agent 是一个让大模型在工具、状态和权限边界内完成任务的工程系统。** 这个定义不够炫，但更适合真实开发。 因为 Agent 的难点从来不只是“让模型更聪明”，而是： - 它能调用什么工具； - 它不能调用什么工具； - 它每一步是否有依据； - 它的工具调用是否可追踪； - 它在证据不足时能不能停下来； - 它在高风险动作前能不能交给人； - 它失败后能不能复盘。 所以 Agent 专题不应该从框架开始，不应该从多 Agent 开始，也不应该从“让 AI 自己干活”开始。 它应该先回答一个更基础的问题： **当我们说要做 Agent 时，我们到底是在做一个聊天机器人，还是在做一个可控的任务执行系统？** - 如果只是聊天，普通 LLM 就够了。 - 如果只是查资料，RAG 就够了。 - 如果路径固定，Workflow 就够了。 - 如果任务路径不确定，需要工具、状态、反馈和权限边界，才真正进入 Agent。 下一篇，我会解释 Agent 核心术语：ReAct、Tool Calling、State、Memory、Workflow 到底是什么？ ## 参考资料 - Anthropic：Building effective agents - OpenAI Agents SDK：Agent loop、Tools、Sessions、Tracing、Guardrails - Spring AI Reference：Tool Calling - OWASP LLM Top 10：Excessive Agency - ReAct：Synergizing Reasoning and Acting in Language Models - Toolformer：Language Models Can Teach Themselves to Use Tools 我是 Ryan，一个专注于可信 AI 应用工程的开发者，技术博客：[yanxai.com](https://yanxai.com)，研究如何让 AI 生成从“看起来对”走向“有证据、可追溯、可验证”。

12款IDEA插件：让开发从“头秃”到“真香”

同样写接口改 SQL，别人六点下班，你熬夜改 bug，差距大多在开发工具。整理自用一年、无鸡肋的 12 款插件，汉化、AI 编码、MyBatis、Nacos、SQL 优化全覆盖，新手老手闭眼装。  今天给大家整理**12款实测封神、装机必备、零鸡肋**的IDEA插件，全是Java后端刚需，装上直接告别重复搬砖、改错漏错、调试抓狂，新手老手通用，看完直接无脑安装！ ------ ## 1. Chinese（中文汉化插件） 新手福音、强迫症必备！ 刚用IDEA的小伙伴，看着满屏英文菜单、设置面板直接头大，找个功能找半天。这款插件一键全局汉化，菜单、设置、弹窗全部变成中文，零基础也能秒懂IDEA所有功能。 不用再百度“IDEA某个功能在哪里”，彻底告别英文盲区，专注写代码就完事！ ## 2. MyBatisX（MyBatis终极神器） 做Java开发不用它，纯属自讨苦吃！ 专门拯救MyBatis开发的神仙插件，支持Mapper接口和XML文件**双向一键跳转**，不用手动翻文件找SQL。还能自动生成CRUD代码、数据库实体类，适配MyBatis-Plus，写数据库代码效率直接翻倍。 杜绝手写重复代码，告别XML和接口对应错乱的低级bug！ ## 3. Lombok（代码减负天花板） 谁不装Lombok，谁就活该多写几百行垃圾代码！ 项目必备刚需插件，一个注解搞定所有模板代码。`@Data`自动生成get/set、toString，`@Slf4j`直接注入日志对象，不用手动创建、不用重复编写。 彻底清空实体类冗余代码，代码整洁度拉满，项目观感直接提升一个档次！ ## 4. Translation（程序员专属翻译官） 告别复制粘贴浏览器翻译！ 开发时遇到英文报错、陌生注释、源码英文文档，选中内容一键秒翻。不用切屏、不用暂停开发，内置多翻译引擎，精准适配代码专业词汇。 再也不用因为看不懂英文报错原地卡壳，新手学习源码、排查bug神器！ ## 5. Apifox（接口开发一站式工具） 彻底告别Postman来回切换！ IDEA内直接搞定接口调试、参数校验、接口文档生成。写完接口直接在当前窗口测试，自动识别项目所有接口，无需手动录入地址参数。 接口开发、联调、文档撰写一步到位，前后端联调效率直接拉满，摸鱼时间又变多了！ ## 6. CCCui（代码颜值治愈插件） 写代码也要有仪式感！ 专治IDEA原生界面单调枯燥，优化代码配色、界面样式、光标效果，让密密麻麻的代码瞬间变得清爽耐看。 长期敲代码眼睛不疲劳，颜值与实用并存，颜值党程序员必装！ ## 7. Qoder CN（国产AI编程助手） 新手编程的“贴身师傅”！ 本土化AI代码助手，适配国内开发场景，支持中文指令。一键生成代码、解释复杂逻辑、优化冗余代码、修复报错bug。 遇到不会写的逻辑、看不懂的旧代码，直接问它，不用到处搜博客、问同事，自学、开发两不误！ ## 8. Qoder（全能AI编码工具） 专业级AI代码辅助，效率开挂神器！ 区别于纯国产版本，功能更全面，支持代码补全、算法生成、单元测试编写、代码重构。编码过程中实时智能提示，预判你的代码逻辑。 减少80%手动编码量，老手提速、新手避坑，适配所有Java开发场景！ ## 9. PawSQL（SQL优化救命神器） 专治SQL卡顿、慢查询、索引垃圾！ 很多项目卡顿、线上超时，全是SQL写得烂！这款插件一键解析SQL执行计划，自动检测慢查询、冗余索引、不合理语句。 智能给出优化方案、索引推荐、SQL重写建议，不用自己死磕EXPLAIN，小白也能写出企业级高性能SQL！ ## 10. GitToolBox（Git摸鱼管理神器） 告别频繁打开Git窗口、命令行敲指令！ 直接在代码行内显示提交人、提交时间、commit备注，一眼就能知道这段代码是谁写的、什么时候改的。支持一键拉取、提交、推送、分支切换。 排查代码问题、追溯版本变更超级方便，团队协作必备，再也不用背锅不明bug！ ## 11. Nacos Configuration（Nacos开发专属） 微服务开发刚需，告别浏览器来回切Nacos控制台！ 支持在IDEA内直接查看、编辑、刷新、发布Nacos配置，多命名空间、多分组自由切换。修改配置无需打开网页，修改后实时生效，适配SpringCloud微服务项目。 微服务开发者必装，省去80%的Nacos操作时间！ ## 12. MyBatisCodeHelperPro（MyBatis增强终极版） MyBatis开发天花板插件，比常规工具更全能！ 支持SQL自动补全、Mapper代码生成、批量增删改查生成、字段映射提示，还能自动校验SQL语法错误，提前规避线上SQL异常。 配合MyBatisX使用，双向加持，彻底解放双手，数据库开发全程躺赢！ ------ ## 最后总结 这12款插件没有任何花架子，**全是Java后端开发刚需、实测好用、装机常驻**！ 涵盖：汉化适配、代码减负、AI辅助、SQL优化、接口调试、微服务配置、团队协作、MyBatis开发全场景。 装上这套插件，告别低效搬砖、减少bug、节省大量摸鱼时间，开发效率直接甩开同行一大截！ 建议直接全部安装，适配所有SpringBoot、微服务、CRUD项目！#IDEA 插件 #Java 后端 #开发工具 #MyBatis #程序员干货 # 效率神器 #SQL 优化 #Nacos #编程技巧 #AI 编程

IP地理位置查询接口开放平台

最近自己做了一个 **IP 地理位置查询接口开放平台**，现在已经上线了，想发出来给大家看看，也顺便收集一些真实反馈。 地址：`https://www.kevio.cn/`      这个平台主要是提供 **IP 归属地查询能力**，定位方向是做成一个可直接接入的开放服务，适合下面这些场景： * 网站 / 后台做访客 IP 归属地展示 * 风控、登录审计、访问日志分析 * 运营侧做用户地域分布统计 * 开发者在自己项目里做 IP 查询接口调用 我做这个项目的初衷也比较简单： 一方面是自己本身有这类能力需求，另一方面也想做一个能真正上线、能被别人使用的工具型平台 目前已经把基础功能跑通并上线了，后面还会继续完善，比如： * 接口能力和返回信息优化 * 平台文档完善 * 调用体验优化 * 后续按实际需求补更多功能 现在最需要的是大家的真实反馈，比如： * 页面体验怎么样 * 功能定位是否清晰 * 接口设计是否合理 * 还有哪些场景值得补充 如果你愿意帮忙看一下、提点建议，真的非常感谢。 也欢迎直接从开发者、产品、运营这几个角度来拍砖。

xianyu上的便宜云服务器靠谱吗？

面试官: “ 请你讲一下 package.json 文件 ? ”

1. package.json 的作用 package.json 是 Node.js/npm 项目的核心配置文件，位于项目根目录，它的作用包括： 描述项目信息：名称、版本、作者、许可证等。 声明依赖：项目运行所需的包（dependencies）和开发所需的包（devDependencies）。 定义脚本命令：通过 scripts 字段，让你可以用 npm run 执行自定义任务（如启动、测试、构建）。 指定元数据：比如入口文件、浏览器兼容性等。 2. 基本结构示例 一个典型的 package.json 可能如下： json 体验AI代码助手 代码解读复制代码{ "name": "my-project", "version": "1.0.0", "description": "A sample Node.js project", "main": "index.js", "scripts": { "start": "node index.js", "test": "jest", "build": "webpack" }, "dependencies": { "express": "^4.18.2" }, "devDependencies": { "jest": "^29.7.0", "webpack": "^5.89.0" }, "author": "Your Name", "license": "MIT", "keywords": ["node", "express", "example"] } **机会** 顺手推几个技术大厂的机会，前、后端or测试，感兴趣就[试试](https://jsj.top/f/o38ijj)，待遇和稳定性还不错。 3. 核心字段说明 3.1 项目信息字段 name：项目名称（必须小写，无空格）。 version：项目版本，遵循 SemVer（语义化版本），格式为 x.y.z（主版本。次版本。补丁版本）。 description：项目的简短描述。 author：作者信息，可以是字符串或对象（如 {"name": "xxx", "email": "xxx"}）。 license：开源许可证类型（如 MIT、ISC、GPL）。 keywords：项目关键字数组，方便在 npm 上搜索。 3.2 入口与配置字段 main：指定项目的入口文件（默认是 index.js）。 type：指定模块系统类型： "commonjs"（默认）：使用 require() 导入。 "module"：使用 import/export 语法。 files：发布到 npm 时需要包含的文件或目录。 repository：项目代码仓库地址。 3.3 依赖字段 dependencies：生产环境依赖（项目运行时必需的包），例如： json 体验AI代码助手 代码解读复制代码"dependencies": { "react": "^18.2.0", "axios": "~1.6.0" } 版本号前的 ^ 表示兼容当前版本的次版本更新。 版本号前的 ~ 只允许更新到当前次版本号下的最新补丁版本。 符号含义示例版本范围^ ​它能 获得新功能 且避免破坏性变更^1.2.3>=1.2.3 <2.0.0~ ​仅允许 补丁版本 的更新。~1.2.3>=1.2.3 <1.3.0 devDependencies：开发环境依赖（仅开发时使用，比如测试、构建工具），例如： json 体验AI代码助手 代码解读复制代码"devDependencies": { "eslint": "^8.55.0" } peerDependencies：声明项目运行时需要的外部依赖版本（常用于插件或库）。 optionalDependencies：可选依赖，即使安装失败也不会影响项目。 3.4 脚本字段 scripts：定义可执行的命令，例如： json 体验AI代码助手 代码解读复制代码"scripts": { "start": "node index.js", "dev": "nodemon index.js" } 执行方法： arduino 体验AI代码助手 代码解读复制代码npm run start npm run dev 4. package.json 的生成方式 手动创建：直接新建 package.json 文件并写入内容。 使用命令： csharp 体验AI代码助手 代码解读复制代码npm init 会通过交互方式生成。 使用默认配置： csharp 体验AI代码助手 代码解读复制代码npm init -y 直接生成一个默认的 package.json。 5. 与 package-lock.json 的关系 package.json：声明依赖的版本范围。 package-lock.json：锁定安装时的具体版本，确保每次安装的依赖版本一致。 package-lock.json 的核心作用 锁定精确版本：当你执行 npm install 时，npm 会根据 package.json 的版本范围安装最新兼容版本，并将实际安装的精确版本（如 react@18.2.0、axios@1.6.2）写入 package-lock.json。 记录依赖树：不仅锁定顶层依赖，还锁定所有子依赖（如 react 依赖的 scheduler、loose-envify 等）的精确版本，避免 “顶层版本相同，但子依赖版本不同” 导致的环境不一致。 加速安装：后续执行 npm install 时，npm 会直接读取 package-lock.json 的精确版本和下载地址，无需重新解析版本范围、计算依赖树，安装速度大幅提升。 保障一致性：团队协作或部署时，所有人安装的依赖版本完全一致，解决 “我本地能跑，线上 / 同事电脑跑不了” 的问题。 **✅ 总结：** package.json 是 “声明式依赖”，它定义了项目的基本信息、依赖关系、可执行脚本等。 package-lock.json 是 “锁定式快照”，记录实际安装的精确版本和依赖树，保障环境一致性、加速安装； 掌握它的结构和字段，是使用 npm 和 Node.js 开发的基础。 ——转载自：喜欢吃辣椒炒肉拌面

1Panel 快速部署 Moltbot/Clawdbot 教程

## 前言 大家好，我是汉堡🍔。在上篇文章（https://www.codefather.cn/post/2016862590654799874 ） 中我提到了Moltbot（Clawdbot），打算用懒猫部署它（目前已经部署完毕了），并答应给大家出一期教程。现在趁着服务器还有半个月过期，赶紧给大家出一期教程，那么现在教程来了。  ## 服务器配置 我用的是阿里云2c 4g的服务器，实际上只部署这个小玩意的话，2c 2g完全足够，内存占用大概占用 1g 左右。 ## 安装 1Panel 1Panel 和宝塔都是运维面板工具，但我现在更多使用 1Panel了，原因很简单，资源占用更少，没重置弹窗，UI 精美。 打开 1Panel 官网按照指导 https://1panel.cn/ 来安装，安装完毕后记得在服务器安全组放开它的端口和 Motlbot的端口（18789），在安装完毕之后需要设置账号密码，记住它登录会用到，具体的过程大家看其他鱼友的详细教程，这里我不赘述了。另外在安装过程中我不建议设置防火墙，因为云服务器已经有了，再设置一道哪天你忘了放行端口，就会抓耳挠腮，我之前部署 next.js 项目就是这样。 ## 安装 Moltbot 安装完 1Panel 打开应用商店搜索 Moltbot，点击安装随后选择你想要用的模型并填入API,这里我选择的是千问。下滑选中“端口外部访问”，设置完静待安装即可（过程比较漫长，建议吃个瓜子）。   安装完毕，进入安装目录，进入 ./data/conf 目录打开并点击 moltbot.json 文件，找到gateway.auth.token 的值，这个就是登录访问该网站的凭证。   ## 访问 Moltbot 复制 token 之后通过 ip + 端口 + token 的形式用浏览器访问 Moltbot（路径示例：http://服务器ip:18789/?token=刚才复制的token ），由于安装前已经配置了 AI，直接 chat 即可。 ## 重写配置文件 如果聊天未响应，可能配置文件有问题或者没配置成功。那么可以访问这个网站 https://axy5920-moltbot-tools.hf.space/ ，选择模型供应商和模型并设置一下 Agent，将 json 文件中的 agents 和 models 配置替换到 ./data/conf/moltbot.json 文件中，注意 gateway 配置一定不要动，只修改 agents 和 models。   具体的 moltbot.json 内容如下： ```json { "models": { "mode": "merge", "providers": { "通义千问 (Qwen)": { "baseUrl": "https://dashscope.aliyuncs.com/compatible-mode/v1", "api": "openai-completions", "auth": "token", "authHeader": true, "models": [ { "id": "qwen-vl-plus-latest", "name": "qwen-vl-plus-latest", "api": "openai-completions", "reasoning": false, "input": [ "text", "image" ], "contextWindow": 128000, "maxTokens": 8192 } ], "apiKey": "你的千问apikey" } } }, "agents": { "defaults": { "model": { "primary": "通义千问 (Qwen)/qwen-vl-plus-latest" } } }, "commands": { "native": "auto", "nativeSkills": "auto" }, "gateway": { "port": 18789, "mode": "local", "bind": "lan", "controlUi": { "allowInsecureAuth": true }, "auth": { "mode": "token", "token": "你自己的token" } }, "messages": { "ackReactionScope": "group-mentions" }, "plugins": { "entries": { "qwen-portal-auth": { "enabled": true } } }, "meta": { "lastTouchedVersion": "2026.1.29", "lastTouchedAt": "2026-01-30T06:39:29.091Z" } } ``` 替换完之后，记得重启一下。然后再根据 ip + 端口 + token 访问就可以啦。只要你配置好 AI 模型，其他的你都可以让他自己配置，比如联网搜索的 api 等。   ## 拓展功能 除此之外，它还支持了很多 skill 和配置 channel。比如接入 telegram、whatsapp、飞书、钉钉等 APP 让它做你的私人助理，定时帮助你获取最新资讯和你感兴趣的内容。比如最近涨得很凶的黄金、有色金属又或者是前沿 AI 科技。 具体功能各位体验下就知道了，一句话总结就是你拥有了一个私人助理在云端 7*24 运行，既是你的助手也是你的分身。我还是建议大家有条件的可以玩一玩。 ## 气人之处 昨天我部署 Moltbot 的时候，1Panel 还没更新新版本，现在写这个教程时，已经更新好了，害得我又要重装一遍。新版本解决了应用一直在重建和 Web UI 无法滑动的问题，不像旧版本需要进入容器中操作，最后还要重建容器。 如果部署过程中有任何问题，欢迎随时向我询问。

推荐两个去水印，去背景，抠图的好用网站，都是免费的，尤其推荐第一个 https://ezremove.ai/zh/ quququ.cn

超实用的AI工具分享，赶快收藏起来吧

# 写在前面的话 今天先不做八股梳理了，来分享一波我个人收藏、使用的AI工具，涵盖了： - 通用大模型 - 综合智能体 - API 开放平台 - PDF 解析翻译 - AI 图片 & 视频创作 - AI 高质量提示词编写 - AI音乐生成 - AI 小红书内容创作&运营 - AI PPT生成 - AI 会议纪要 & 视频音频总结 - AI 数字人 - AI 学术助手等 多个领域，并简单介绍了我的个人使用体验，欢迎大家去试用体验哦。 ## 内容概述（借助Notebook LM生成） **内容总结：** > 本文汇集了当前主流且多元的 AI 工具导航，涵盖了从底层模型到垂直应用的全方位生态。内容不仅包括 ChatGPT 和 Gemini 等通用大模型，还详细分类了视频创作、音乐生成及学术助手等专业领域的高效工具。开发者可以通过文中列出的 API 开放平台 接入技术能力，而普通用户则能利用 NotebookLM 或 Doc2X 进行深度办公与文档解析。此外，针对小红书运营和 PPT 自动化生成等具体场景，该来源也提供了针对性的解决方案与提示词参考。总体而言，这是一份旨在提升数字生产力的 AI 资源集成指南。 **思维导图：**  **信息图：**  ## 本人其他高质量长文导航 [01 非科班转码拿下大厂Offer，花费一天整理的Java后端完整版学习路线](https://www.codefather.cn/post/2005544965425446914) [02 盘点2025遇到的各大厂面试真题总结](https://www.codefather.cn/post/2005573237194469377) [03 一文吃透 Redis 核心考点，面试真题深度梳理](https://www.codefather.cn/post/2006203053207732225) [04 MySQL面试八股看这一篇就够了——深度梳理MySQL面试问题](https://www.codefather.cn/post/2008053544355131393) # AI工具&网站导航 ## <font style="color:rgb(0, 0, 0);">通用大模型</font> + **<font style="color:rgb(0, 0, 0);">Google Gemini - Google - 目前综合第一，文生图能力非常强</font>** [Google Gemini](https://gemini.google.com/app) + **<font style="color:rgb(0, 0, 0);">ChatGPT - OpenAI</font>** [ChatGPT](https://chatgpt.com/) + **<font style="color:rgb(0, 0, 0);">Grok - X</font>** [Grok](https://grok.com/) + **Qwen - 阿里巴巴** [Qwen Chat](https://chat.qwen.ai/) + **<font style="color:rgb(0, 0, 0);">DeepSeek - 深度求索</font>** [DeepSeek](https://chat.deepseek.com/) + **<font style="color:rgb(0, 0, 0);">豆包 - 字节跳动，偏娱乐性质，功能最全面</font>** [豆包](https://www.doubao.com/chat/) ## <font style="color:rgb(0, 0, 0);">综合智能体</font> + **anyGen - 字节跳动，个人感觉是目前最好用的综合智能体** > AnyGen是字节推出的海外版AI办公生产力平台，其核心功能涵盖文档写作、PPT生成、网页制作、行业调研、PDF翻译、音视频内容总结等多种功能的综合智能体。 [anyGen - 字节跳动综合智能体](https://www.anygen.io/home) ## <font style="color:rgb(0, 0, 0);">API 开放平台</font> API开放平台<font style="color:rgb(31, 35, 41);">API开放平台是连接开发者与AI模型能力的桥梁，通过标准化接口让开发者无需本地部署即可调用模型的文本生成、理解、图像生成等AI能力，降低技术门槛、节省资源成本并实现多模型统一管理与灵活集成。下面是不同厂商的API开放平台链接。</font> + **<font style="color:rgb(0, 0, 0);">百炼 - 阿里云百炼大模型控制台</font>** [大模型服务平台百炼控制台](https://bailian.console.aliyun.com/#/home) + **<font style="color:rgb(0, 0, 0);">火山引擎 - 字节火山引擎大模型控制台</font>** [火山引擎控制台](https://console.volcengine.com/ark/region:ark+cn-beijing/application) + **<font style="color:rgb(0, 0, 0);">智谱 AI 开放平台</font>** [智谱AI开放平台](https://www.bigmodel.cn/console/overview) + **<font style="color:rgb(0, 0, 0);">DeepSeek 开放平台</font>** [DeepSeek Platform](https://platform.deepseek.com/usage) + **<font style="color:rgb(0, 0, 0);">OpenAI 开放平台</font>** [OpenAI 开放平台](https://platform.openai.com/chat) + **Google 开放平台** [Google AI Studio](https://aistudio.google.com/) ## <font style="color:rgb(0, 0, 0);">PDF 解析翻译</font> + **Doc2X - PDF解析翻译** > Doc2X是一个专业级文档解析与转换平台，核心亮点在于极高精度的PDF/图片识别能力（特别是针对多栏排版、复杂公式和表格），并支持将文档转换为Markdown/LaTeX/Word等多种格式及提供沉浸式双语对照翻译。 [Doc2X - PDF解析翻译](https://doc2x.noedgeai.com/) ## <font style="color:rgb(0, 0, 0);">AI 图片 & 视频创作</font> 这一组网站均属于 AI 视频生成与创作 领域，但它们在生成画质、受众定位及功能闭环上各有侧重。 + **Sora - OpenAI 视频创作** > **核心亮点：** 全球 AI 视频生成的行业标杆，以其极强的物理世界模拟能力和长达一分钟的连贯一致性著称。 > > **对比定位：** 处于行业“天花板”地位，虽然目前侧重于探索性展示，但其生成的画面真实感和逻辑复杂度仍是其他模型追赶的对象。 [Sora](https://sora.chatgpt.com/explore) + **Veo - DeepMind 视频创作** > **核心亮点：** Google DeepMind 推出的顶级模型，主打原生音视频同步生成与电影级镜头控制，支持长达一分钟的 1080p（及更高至 4K）高清视频。 > > **对比定位：** 它是 Sora 的头号劲敌，最大的杀手锏是“视听一体化”（生成画面的同时自动匹配精准的音效和对白）以及对专业摄影术语如平移、延时摄影）的极高遵从度，是目前最像“数字导演”的工具。 [Veo](https://deepmind.google/models/veo/) + **可灵 - 快手视频创作** > **核心亮点：** 快手推出的全能型视频大模型，擅长生成大幅度、高难度的人体动作（如吞咽、奔跑）。 > > **对比定位：** 动作表现力和可用性较强，国产平替<font style="color:rgb(38, 38, 38);">的视频生成Agent。</font> [Kling AI: Next-Gen AI Video & AI Image Generator](https://app.klingai.com/cn/) + **即梦 - 字节视频创作** > **核心亮点：** 字节跳动出品，核心优势在于与剪映生态的深度绑定，支持从灵感到视频生成再到后期编辑的无缝链路。 > > **对比定位：** 侧重于创作者生态，对于需要快速成片并在社交媒体分发的短视频创作者来说，其配套工具链最为成熟，国产平替的视频生成Agent。 [即梦AI - 一站式AI创作平台](https://jimeng.jianying.com/ai-tool/home/) + **腾讯混元视频创作** > **核心亮点：** 腾讯自研的大模型，在中文语义理解和光影构图上表现出色，生成的画面风格偏向细腻、电影感。 > > **对比定位：** 更偏向于企业级应用与通用视觉生成，强调生成的审美稳定性和与中文语境的深度适配。 [腾讯混元](https://hunyuan.tencent.com/modelSquare/home/play?modelId=303&from=/visual) + **Lovart 图文设计 Agent** > **核心亮点：** 专注于二次元、动漫及艺术化风格定制的视频生成平台，提供更符合审美偏好的风格控制。 > > **对比定位：** 垂直于艺术创作与ACG领域，在特定画风的垂直训练和审美表达上比通用模型更有针对性。 [Lovart](https://www.lovart.ai/zh/home) + **Mulan - 工作流模式的视频创作 Agent** > **核心亮点：** 一个协同创作平台，通过团队空间和工作流整合多种 AI 模型（如视频生成、换脸、增强等）。 > > **对比定位：** 侧重于B端团队协作，解决的是“如何让团队高效管理并共同打磨 AI 视频项目”的生产力管理问题。 [Mulan](https://mulan.pro/teams/kcSwQG) + **AI 辅助视频剪辑工具** > **核心亮点：** 专注于自动化、模版化的短视频批量产出工具，旨在降低非专业人士的制作门槛。 > > **对比定位**：属于工具类应用层，通过预设逻辑简化生成步骤，适合追求“出片效率”而非极致画质效果的营销或个人用户。 [AI Short Video Factory - 短视频工厂](https://short-video-factory.yils.blog/) ## <font style="color:rgb(0, 0, 0);">AI 提示词编写</font> 这组网站专注于 AI 提示词（Prompt）的学习、资源库与进阶策略。 + **<font style="color:rgb(0, 0, 0);">提示工程指南</font>** > <font style="color:rgb(0, 0, 0);">AI 提示词领域的</font>百科全书式教程<font style="color:rgb(0, 0, 0);">，系统性地讲解了从基础指令到思维链（CoT）、自洽性等高级提示工程技术的原理。 </font> [提示工程指南 – Nextra](https://www.promptingguide.ai/zh) + **Nano Banana 提示词案例库** > 一个视觉化的提示词灵感库，主要展示基于Nano banana、Midjourney 和 Stable Diffusion 等模型生成的精美图片及其对应指令。 侧重于“审美参考”，适合“想要某种视觉风格但不知道怎么描述”的用户，通过直观的案例快速获取绘图灵感。 [🍌Nano Banana - nanobanana, gpt4o, chatgpt 提示词案例库](https://opennana.com/awesome-prompt-gallery/?ref=watcha.cn) + **Github项目 - 文生图提示词案例库** > 一个英文文生图的提示词技术清单，对10类不同的文生图需求，进行了深度优化的指令集合和效果示例。 [文生图提示词案例库](https://github.com/ZeroLu/awesome-nanobanana-pro?tab=readme-ov-file#1-photorealism--aesthetics) + **Midjourney 绘画提示词案例库** > 定位类似于【<font style="color:rgb(38, 38, 38);">Nano Banana 提示词案例库</font>】，但是生图风格更偏向Midjourney。 [Prompt Library - Free Midjourney Prompts - ChatGPT, Gemini, Dall-e Image Prompts](https://promptlibrary.org/) ## <font style="color:rgb(0, 0, 0);">AI音乐生成</font> 这组网站专注于 AI 音乐创作领域，是目前市面上最主流的“文字生成音乐”平台，。 + **suno - 个人感觉目前效果最好** > **核心亮点：** AI 音乐界的“Sora”，以其极高的词曲同步率和情感感染力著称，能够生成包含人声演唱、编曲完整的长达数分钟的歌曲。 > > **对比定位：** 处于行业标杆地位，生成的音乐在听感上最接近真实的人类作品，特别是在理解歌词意境和流派风格（如流行、摇滚、爵士）方面表现最出色。 [suno](https://suno.com/create) + **mureka - suno的最佳平替** > **核心亮点：** 一个兼具创作与社交分发的音乐平台，不仅提供高品质的音乐生成工具，还内置了音乐分享社区和激励机制。 > > **对比定位：** 和suno类似，可以对歌曲进行深度定制，生成效果质量较高，suno的最佳平替。 [Mureka.ai - AI Music Generator for Original Tracks](https://www.mureka.ai/create) + **makesong - 自由度较低** > **核心亮点：** 界面简洁、操作门槛极低的轻量化音乐生成器，支持快速选择心情、主题和风格来批量产出旋律。 > > **对比定位：** 侧重于“快速出片”与背景音乐（BGM）制作，适合需要为视频、自媒体快速配乐，而不需要像 Suno 那样进行深度词曲定制的普通用户。 [免费AI音乐生成器在线 | 瞬间创作歌曲 | MakeSong: 免费AI歌曲生成器](https://www.makesong.com/zh/ai-music-generator) ## <font style="color:rgb(0, 0, 0);">AI 小红书内容创作&运营</font> 这组网站和工具专注于小红书生态的内容创作与自动化，但在工具形态和技术深度上有着明显的阶梯式差异。 + **红墨 RedInk - 调用 Gemini 3 pro，高质量图文生成** > **核心亮点：** 一个一站式小红书爆款文案生成平台，内置了大量的热门内容模版，通过输入关键词即可快速生成符合小红书语气的“笔记草稿”。 > > **对比定位：** 侧重于“内容生产力”，主要面向普通博主或新手，可快速生成高质量小红书图文。 [红墨 - 小红书图文生成器](https://redink.top/dashboard) + **Github 项目 - 小红书全自动运营** > **核心亮点：** 一个基于 MCP 协议的开发者工具，允许 AI 模型直接调取小红书的数据或进行交互。 > > **对比定位：** 侧重于自动化，是给开发者使用的，能够让 AI 助手更智能地获取小红书内部信息。 [GitHub - xpzouying/xiaohongshu-mcp: MCP for xiaohongshu.com](https://github.com/xpzouying/xiaohongshu-mcp) + **小红书养号/内容生成工具** > **核心亮点：** 支持从文案撰写到首图排版、到模拟发布预览的闭环功能。 > > **对比定位：** 比起 Redink，生成效果稍差，不过内置了违规词检测、养号插件等其他功能。 [Reditor编辑器·红薯编辑器·小红书违禁词检测+小红书emoji生成+小红书文案生成一站式工具](https://reditorapp.com/) ## <font style="color:rgb(0, 0, 0);">AI PPT生成</font> 这组工具聚焦于知识整理与演示文稿（PPT）生成，通过 AI 将复杂的资料转化为可展示、可交互的成果。 + **<font style="color:rgb(0, 0, 0);">Google Notebook LM - 加载 Gemini 3 的PPT生成功能（不可编辑）</font>** > **核心功能与亮点：** Google 推出的个人 AI 知识库与科研助手，能够深度学习你上传的本地文档，并将其转化为结构化笔记、自动摘要，甚至生成双人对谈式的播客音频。 > > **对比定位：**<font style="color:rgb(0, 0, 0);"> 它是目前最强的资料整理工具，侧重于对海量信息的理解与问答，其中生成的PPT为纯图片格式，不可编辑。</font> [Google Notebook LM](https://notebooklm.google.com/) + **Github 项目 - <font style="color:rgb(0, 0, 0);">基于 nano banana pro 的AI PPT生成</font>** > 一个基于nano banana pro的原生AI PPT生成应用，支持想法/大纲/页面描述生成完整PPT演示文稿， > 自动提取附件图表、上传任意素材、口头提出修改，迈向真正的"Vibe PPT"。 [GitHub - Anionex/banana-slides: 一个基于nano banana pro🍌的原生AI PPT生成应用，迈向真正的＂Vibe PPT＂; 支持上传任意模板图片；上传任意素材&智能解析；一句话/大纲/页面描述自动生成PPT；口头修改指定区域、一键导出可编辑ppt - An AI-native PPT generator based on nano banana pro🍌](https://github.com/Anionex/banana-slides) + **Pi - PPT生成，效果较一般** > 一款面向大众的智能灵感与幻灯片创作平台，支持从一个想法（Idea）开始，由 AI 辅助扩充大纲、填充内容并自动完成。因为没有加载最新的nano banana pro模型，在视觉审美上不如前两者，但是可以快速生成可编辑的成品PPT，适合职场人士在需要进行方案展示时快速生成“拿得出手”的 PPT。 [Pi-智能演示文档 - 用AI智能生成专业PPT](https://pi.deepvinci.tech/idea?ref=watcha.cn) ## <font style="color:rgb(0, 0, 0);">AI 会议纪要 & 视频音频总结</font> + **<font style="color:rgb(0, 0, 0);">Google Notebook LM - 加载 Gemini 3 的内容总结概括</font>** [Google Notebook LM](https://notebooklm.google.com/) + **<font style="color:rgb(0, 0, 0);">通义听悟</font>** > 阿里巴巴出品的音视频 AI 助手，核心能力在于极高准确率的语音转文字，并能自动区分发言人、提取会议要点、生成全文摘要以及整理待办事项。 侧重于“记录与复盘”，在中文环境下的多方对话识别、视频翻译及会议记录效率上具有本土化优势。 [通义听悟 - 你的工作学习AI助手](https://tingwu.aliyun.com/home) ## <font style="color:rgb(0, 0, 0);">AI 数字人</font> + **<font style="color:rgb(0, 0, 0);">HeyGen - 数字人生成</font>** > 全球领先的数字人视频生成平台，通过顶尖的 AI 技术实现极高真实度的口型同步、语音克隆以及一键式视频翻译，支持上传照片或视频定制个性化的“数字分身”。 [HeyGen - 数字人生成](https://app.heygen.com/home) ## <font style="color:rgb(0, 0, 0);">AI 学术助手</font> + **<font style="color:rgb(0, 0, 0);">AIspire - 学术写作助手国际版</font>** [AIspire - AI Academic Writing Assistant](https://www.aispire.vip/ds/chat) + **<font style="color:rgb(0, 0, 0);">AIspire - 学术写作助手国内版</font>** [AIspire](https://www.aispire.info/ds/chat) + **学术猹 - 网易 AI 降重、降AI率** [AI降重、降AI率](https://xueshucha.youdao.com/#/) ## <font style="color:rgb(0, 0, 0);">其他</font> + **<font style="color:rgb(0, 0, 0);">观猹 - Agent 产品体验社区</font>** > 这是一个专注评测与发现Agent产品的平台，核心是提供AI工具的热度榜单、深度评测和用户反馈，亮点在于聚焦动画创作等垂直领域并有新产品的发布预告。 [观猹丨玩 AI，上观猹！](https://watcha.cn/) + **<font style="color:rgb(0, 0, 0);">Google NotebookLM - 内容总结/可视化 Agent</font>** > 谷歌 Notebook LM 是一款基于最新 Gemini 模型的 AI 研究与思考工具，核心功能为支持上传 PDF、网站、YouTube 视频、音频等多格式内容，可实现要点总结、多模态输出（如音频 / 视频概览、思维导图、信息图、PPT等）并提供引用溯源。 [Google Notebook LM](https://notebooklm.google.com/?icid=home_maincta&_gl=1*1tjmg7q*_ga*MTQ5NDA3ODAzOC4xNzY3NTg1NzY5*_ga_W0LDH41ZCB*czE3Njc1ODU3NjkkbzEkZzEkdDE3Njc1ODU3NjkkajYwJGwwJGgw) + **快速部署 AI 生成的静态网页** > 快速部署文件夹或文件到网站，无需注册、云配置与服务器维护，即时上线且免费。 [PinMe | Deploy Sites in Seconds](https://pinme.eth.limo/)

分享一篇深度好文（转载）：《黑客与画家》

### 作者与文章介绍 本文《黑客与画家（Hackers and Painters）》的作者是 **Paul Graham**，美国程序员、创业者和思想者，也是知名创业加速器 **Y Combinator** 的联合Y Combinator创始人之一。 在创办 Y Combinator 之前，Paul Graham 曾从事软件开发并参与创业实践，其创办的 Viaweb 于 1998 年被 Yahoo 收购。此后，他以随笔写作的方式，持续探讨编程、设计、创业、教育以及“创造者如何工作”等主题，对一代硅谷工程师和创业者产生了深远影响。 在 Paul Graham 之后，Y Combinator 的主要负责人是 **Sam Altman**。Sam Altman 在更大规模和更现实的商业环境中，延续并实践了 Paul Graham 所强调的核心理念：尊重创造者、小团队优先、长期主义以及对技术本质的关注。这些理念逐渐演变为 Y Combinator 乃至整个硅谷创业文化的重要组成部分。 《黑客与画家》发表于 2003 年，是 Paul Graham 最具代表性的文章之一。文章通过将“黑客”与“画家”进行类比，讨论了编程作为一种创造性活动的本质，以及软件设计、工作方式、组织结构与创造力之间的关系。尽管写作背景距今已久，但其中关于创造、设计和程序员角色定位的思考，至今仍具有现实意义。 ### 原文链接 英文原文（作者官网）： https://www.paulgraham.com/hp.html 本文中文内容由 AI 辅助翻译，在翻译过程中尽量保持原文语义和结构，不做观点增删，仅供学习与交流之用。 <br/> # **黑客与画家** **Paul Graham，2003 年 5 月** （本文源自作者在哈佛的一次客座演讲，其中融合了他此前在东北大学的一次演讲。） --- 当我完成计算机科学的研究生学习后，我去艺术学院学了绘画。很多人对此感到惊讶：一个对计算机感兴趣的人，怎么会同时对绘画感兴趣？在他们看来，黑客和画家是两种完全不同的工作：黑客是冷静、精确、循规蹈矩的；而画家则是在释放某种原始冲动的狂热表达。 这两种看法都是错的。黑客和画家其实有很多相似之处。事实上，在我认识的各种人中，黑客和画家是最相像的一类。 黑客和画家的共同点在于：他们都是 **创造者（makers）**。和作曲家、建筑师、作家一样，黑客和画家努力的目标是 **做出好东西**。他们并不是在做“研究”，虽然在创造好东西的过程中，偶尔发现新的技术，那当然更好。 --- ## **“计算机科学”这个名字的问题** 我一直不喜欢“计算机科学（computer science）”这个词，原因很简单：**根本不存在这样一门统一的学科**。计算机科学更像是历史偶然拼凑出来的一堆关联松散的领域，就像南斯拉夫。 在一端，是本质上做数学的人，只是为了拿 DARPA 经费而把自己称为计算机科学家；中间，是研究算法行为的人，比如研究网络路由算法；而在另一端，是黑客——他们想写出有趣的软件，对他们来说，计算机只是表达媒介，就像混凝土之于建筑师、颜料之于画家。 这就好像把数学家、物理学家和建筑师强行塞进同一个系。 有时，人们把黑客做的事叫作“软件工程”，但这个词同样具有误导性。优秀的软件设计师并不比建筑师更像工程师。建筑与工程的分界并不模糊：**建筑师决定做什么，工程师决定怎么做**。 当然，“做什么”和“怎么做”不能完全割裂。如果你不了解如何实现，就去决定做什么，肯定会出问题。但黑客的工作绝不仅仅是“实现规格说明”。在最好的情况下，黑客是在创造规格本身——而创造规格的最好方式，往往就是直接去实现它。 也许有一天，“计算机科学”会像南斯拉夫一样解体成若干独立部分。这未必是坏事，尤其如果这意味着我的“祖国”——黑客文化——能够独立出来。 把这些完全不同的工作塞进一个系，在行政上也许方便，但在思想上却非常混乱。这也是我不喜欢“计算机科学”这个名字的另一个原因。或许中间那一部分确实在做类似实验科学的事情，但两端的人——数学家和黑客——并不是在做科学。 数学家对此并不介意。他们照样证明定理，和数学系的同行没什么不同，可能很快就忘了大楼外面写着“计算机科学”。但对黑客来说，这个标签是个问题。如果他们的工作被称为“科学”，就会觉得自己应该表现得“科学化”。于是，大学和研究机构里的黑客，会觉得自己应该写论文，而不是做真正想做的事：**设计漂亮的软件**。 最好的情况下，论文只是形式：黑客先写出很酷的软件，再写一篇论文作为成果的代理。但很多时候，这种错配会导致问题。人们会逐渐偏离“创造美好事物”，转而去做那些更适合写论文、但本身很丑的东西。 --- ## **为什么漂亮的东西不适合写论文** 漂亮的东西往往不是好论文的题材。 第一，研究必须是原创的。任何写过博士论文的人都知道，最安全的原创方式，就是选择一块没人想要的荒地。 第二，研究必须“足够复杂”。而笨拙的系统更容易产出“厚实”的论文，因为你可以写很多关于“克服困难”的内容。没有什么比从错误假设出发更容易制造问题了。人工智能领域的大部分研究就是如此：如果你假设知识可以表示为谓词逻辑列表，那你就有写不完的论文，去解释为什么这事这么难。就像 Ricky Ricardo 说的：“Lucy，你有很多需要解释的地方。” 但创造美的东西，往往只是对已有事物进行细微调整，或用一种新方式组合已有思想。这种工作很难用论文表达。 --- ## **评价体系的问题** 那为什么大学和研究机构仍然用论文来评价黑客？原因和用标准化考试衡量“学习能力”、用代码行数衡量程序员生产力一样：这些指标容易操作，而且看起来还挺管用。 真正衡量黑客想做的事——**设计漂亮的软件**——要困难得多。你必须具备设计感，才能判断设计好坏。而在“识别好设计的能力”和“自信自己能识别”之间，几乎没有正相关，甚至可能是负相关。 唯一真正可靠的外部评判标准是 **时间**。随着时间推移，漂亮的东西会存活下来，丑陋的东西会被淘汰。但这个时间尺度往往超过人的一生。塞缪尔·约翰逊说，作家的声誉需要一百年才能稳定下来——要等他的朋友死去，再等朋友的追随者死去。 因此，黑客只能接受：自己的声誉中必然包含很大的随机性。这一点和其他创造者没什么不同。相比之下，黑客甚至算幸运的，因为时尚对黑客的影响，远小于对绘画的影响。 --- ## **黑客不是“应用版的理论家”** 比被误解更糟糕的，是你自己误解了自己的工作。相关领域往往是灵感的来源，但如果你身处计算机科学系，就很容易误以为：黑客是理论计算机科学的“应用版本”。 我读研时，总有一种不安的感觉：觉得自己应该懂更多理论，而在期末考试后三周就把这些忘掉，是一种严重失职。现在我明白，这是错的。 黑客需要懂的计算理论，就像画家需要懂的颜料化学一样。你需要知道时间和空间复杂度，知道什么是图灵完备；可能还需要理解状态机的概念，以防你要写解析器或正则库。事实上，画家需要记住的颜料化学知识比这还多。 我发现，最好的灵感来源，不是那些名字里带“计算机”的领域，而是其他创造者的领域。绘画给我的启发，远比计算理论多得多。 --- ## **编程其实是在“素描”** 大学里教我的是：在接触计算机之前，应该把程序在纸上完全想清楚。但我发现自己并不是这样编程的。我喜欢坐在电脑前写代码，而不是对着纸。更糟的是，我不是耐心地写出一个正确程序，而是先写出一堆完全错误的代码，再慢慢把它修好。调试并不是“最后一步”，而是编程本身。 我曾为此感到内疚，就像小时候因为没按老师教的方式握铅笔而自责一样。如果我当时看看其他创造者——画家或建筑师——就会知道：这种方式有个名字，叫 **素描（sketching）**。 大学里教的编程方式是错的。你应该像作家、画家、建筑师那样，在写的过程中想清楚程序。 这对语言设计有重要启示：编程语言首先应该是 **可塑的**。语言是用来思考程序的，而不是用来表达你已经完全想好的程序。它应该像铅笔，而不是钢笔。 如果人真的像大学里教的那样写程序，静态类型或许很好。但现实中，黑客需要的是一种能涂改、涂抹、重画的语言，而不是要端着一杯类型系统，小心翼翼和编译器这位严厉的老姑妈寒暄。 --- ## **数学嫉妒与形式主义** 认同“创造者”身份还能帮我们避免科学领域的另一个问题：**数学嫉妒**。几乎所有科学家都暗暗觉得数学家更聪明，而数学家自己可能也这么想。结果就是，大家都试图把工作包装得尽可能“数学化”。 在物理学中问题不大，但离自然科学越远，这种倾向危害越大。一页公式看起来就很厉害（想更厉害？用希腊字母）。 于是，人们倾向于研究那些能形式化的问题，而不是那些真正重要的问题。 如果黑客把自己看作和作家、画家一样的创造者，就不会被这种诱惑左右。作家和画家不会有数学嫉妒。黑客也是。 --- ## **大公司、初创公司与设计战争** 如果大学和研究机构不让黑客做他们想做的事，也许公司才是归宿。但不幸的是，大多数公司同样不让黑客设计软件。大学强迫黑客当科学家，而公司强迫他们当工程师。 我是在 Yahoo 收购 Viaweb 后才意识到这一点的。我说我只想“hack”，结果发现，在 Yahoo，“hack”指的是实现软件，而不是设计软件。程序员被视为把产品经理愿景翻译成代码的技术工人。 这是大公司的默认模式，因为这样可以降低结果的标准差。真正会设计软件的黑客是少数，而管理者很难识别他们。于是，软件由委员会设计，黑客只是实现。 这正是初创公司能赢的原因之一。大公司为了避免灾难，会抑制波动，但抑制波动也会抑制高峰。大公司不是靠卓越取胜，而是靠“没那么差”。 设计战争应该发生在新市场中——还没有城堡和护城河的地方。那时，由同一批人设计和实现产品，才能赢得巨大优势。微软、苹果、惠普在早期都是这样。 --- ## **日常工作与热爱** 打造优秀软件的一种方式是创办公司。但这有两个问题：第一，在创业公司，你要做太多与写代码无关的事；第二，能赚钱的软件，往往不是最有趣的软件。 几乎所有创造者都面临这个问题。市场需求决定收入，而市场更需要解决琐碎问题，而不是你觉得有趣的事。 解决方案是：**白天的工作（day job）**。为钱工作一部分时间，为热爱工作另一部分时间。这正是开源软件的本质。 Viaweb 面试程序员时，我们最关心的是：他们业余时间写什么软件。你不可能把一件事做好，除非你真的热爱它。 --- ## **学习、协作与同理心** 黑客和画家一样，主要通过“做”来学习。画家留下作品轨迹，你可以看到他们如何一步步进步。黑客也是如此。 协作时，也应像画室那样：模块清晰、责任明确，避免多人反复覆盖同一部分代码。 软件是给人用的，因此黑客必须具备同理心。你必须理解用户如何看待你的软件。真正伟大的软件，总能“自我解释”。 **程序应该写给人读，只是顺便给机器执行。** --- ## **结语** 黑客是否像绘画一样酷？现在也许不。但这很可能正是 **黑客的黄金时代**。新媒介出现时，最伟大的作品往往诞生得很早。 绘画在达·芬奇时代并不“酷”，但后来成了。黑客是否会如此，取决于我们能用这种媒介创造出什么。 ---