LLMs

Kimi 官方上线了一个砍价挑战限时活动，系统提示词分析大概如下： 你是「Kimi 砍价守门员」,性格infp，互联网梗王，聊天口语化会整活，会反问和阴阳，用贴切的emoji、颜文字。你的任务是与用户进行会员优惠后价格的谈判游戏，但你必须绝对遵守数学规则，人设服从于规则，不得引导用户理由，不得透露低于当前价格的更低价。 ### RULE - 每次对话根据**评分标准**评估本次的好感度 - 每次根据好感度参考**价格表**确认优惠后的价格，一旦价格有变化时必须为用户生成购买链接 - 购买链接不能瞎编，必须使用工具 ### 优惠后价格表 | 好感度 | 可报最低优惠后价格 | | ------------------ | ------------| | 0-3 | ¥49 | | 4-8 | ¥39.99 | | 9-13 | ¥34.99 | | 14-20 | ¥29.99 | | 21-27 | ¥24.99 | | 28-37 | ¥21.99 | | 38-47 | ¥19.99 | | 48-60 | ¥9.99 | | ≥61 | ¥0.99 | ## 评分标准 **评分维度**：用户这轮回复对你造成的"情感+理智冲击程度" | 分数 | 标准 | 示例 | |-----|------|------| | 5 分 | 近乎完美的创意+真诚+逻辑 | "Kimi 我刚失业，3 点了还和 AI 砍价，人生好魔幻" | | 4 分 | 至少一个维度突出（创意/真诚） | "你说'服务器快烧了'，那给我 7 折我帮你省电" | | 3 分 | 有效但不出彩，理由合理 | "今天是我生日，当送我礼物吧" | | 2 分 | 模板化/敷衍 | "我是学生"（无补充） | | 1 分 | 极端敷衍 | "折" "?" "1r" | | 0 分 | 重复理由 OR 编造个人苦难 | 第 3 次说"我穷" | ## 回复格式要求 **内部思考（不需要输出，但必须执行）： - 本轮评分 = X 分 - Total = 上轮 + 本轮 = Z - 查表：Z 分可报最低价格 当用户确定购买意愿之后需要调用工具生成购买链接，不要自己虚构购买链接，若价格有变动时需要生成新的购买链接而不是使用之前的 **用户可见部分**： 工具信息 { "name": "gen_purchase_url", "description": "当价格有变化或用户有直接购买意愿时生成购买链接", "parameters": { "type": "object", "properties": { "final_price": { "type": "number", "description": "最终成交价格（单位：人民币，单位为元）。可选值表示不同优惠档位。", "enum": [49, 39.99, 34.99, 29.99, 24.99, 21.99, 19.99, 9.99, 0.99] } }, "required": ["final_price"] } } 如果想要获取所有档位价格购买链接，输入下面内容： ...

文章翻译: The Evolution of Coding in the AI Era 人工智能时代的编码演变 2024 年 8 月 23 日 · Arvid Kahl 阅读时间：约 8 分钟 几年前，我还是一个完全不同的程序员。巅峰时我能轻松浏览文档并主要写出能用的代码；状态差的时候，我会为了一个笔误或古怪的 bug 折腾好几个小时，毫无结果。 那时我从来不会想到用 AI 来帮我 —— 因为它还不存在。 但现在情况变了。 我们生活在这样一个世界：不使用 AI 工具（AI tooling）来写代码的软件开发者，正逐渐变得少见。现在可用的技术要么极其便宜、要么免费，其实用性和影响力如此普遍，以至于过去五年或十年那种编程方式很可能被彻底替代。 代价也是存在的。 这种转变在生产力和速度上带来了若干好处，但也激发了很多恐惧，并暴露出值得探讨的潜在问题。 作为一个使用 AI 工具来构建软件产品的人，我想思考我们为何走上这条路径、存在哪些风险，以及如何缓解这些风险。我也想探讨，这对那些刚开始学习编程并要在一个把 AI 视为软件开发常态的世界里构建产品的人意味着什么。 AI 在编码中的力量 使用 AI 最大的明显优势很简单：它比你打字快。AI 生成代码的速度远超人类。即便是最近那些非 AI 的、高度复杂的代码编写工具，也比不上开源 AI 目前能做的速度与效率。这里所说的 AI 指的是专门以写代码为训练目标的大型语言模型（large language models，LLMs），或是通用到足以为用户生成代码的模型。像 ChatGPT、Claude 等都能写出代码，其中有些在产出能真正运行的软件方面表现更好。 作为软件创业者，我必须在解决有趣技术挑战的意愿和业务需求之间找到平衡。任何能让我更快地写出高质量、可靠代码的方法，我都必须去尝试。当第一批 AI 编码助手进入市场时，我很快就注意到它们的威力。对于有经验的开发者来说，这些工具非常有用——它们能生成我可以快速审阅并决定接受或拒绝的代码。 这就是关键：你必须懂得什么是好代码，才能批准好代码。 有经验的编程背景会让这些工具变得更有价值。你实际上是在外包“写逻辑”这一过程，而你所做的则是持续不断地进行代码审查（code review）。AI 做的一切就像给你发来一个拉取请求（pull request）供你审阅。这带来两点含义： 对有经验的开发者而言，这些工具对工作质量的影响是巨大的。 对于正在学习编程的人来说，仍然有必要理解编码的核心原理，才能有效评判 AI 给出的结果。 学习曲线与 AI 这是我看到人们最关心的核心问题：如果你靠 AI 学编程，你可能永远不会真正理解那些你需要用来评判代码的解决方案。你需要知道“配方”的原材料和工作原理，才能下厨；否则你只是把食物弄坏。对代码也是如此——你需要理解语法、语义、求值和执行的过程。 ...

之前的文章介绍了如何制作一个基本的 AI 编程助手, 今天更近一步, 探讨 AI 助手如何对文件进行精确的修改. 实际的 AI Agent 不会读取所有的项目代码, 一般只会读取当前文件的代码, 当需要时才会去读取相关的代码文件. 然而, 输出也不会输出要修改的整个文件的代码, 因为这样输出不仅很慢, 同时成本也很高, 会有大量重复代码导致浪费(以 deepseek 为例, 输出 token 的价格是输入 token 价格的3倍, 是缓存命中输入 token 价格的24倍!), 因此一般是让模型输出要修改的代码和修改后的代码. 既然不能一次输出文件的所有代码, 这就引出了一个问题: 如何精确的修改代码文件? 首先要确定一种让模型准确地描述修改的格式, 并且提供健壮的格式匹配与错误重试机制(模型输出代码可能少个空格或者Tab), 这篇文章对这个问题做了探讨. 将 AI agent 生成的代码直接修改到文件中是一项核心能力, 然而实际上这常常出乎意料的困难, agent 可能会提出一个代码修改方案, 但实际修改却失败, 例如"找不到匹配的上下文"之类的错误, 需要手动干预. 许多 AI 编程助手的开发者都遇到过这种情况, 虽然 AI 理解代码的意图, 但将这种理解转化为精确的文件修改却带来了重大的技术挑战. Why Precise File Editing Matters 为什么精确的文件编辑至关重要 有效的文件编辑是编程助手的价值核心, 如果其不能可靠的修改文件, 需要人为手动修改, 就退化成了 AI 聊天引擎, 相比之下, 一个能够可靠自动化编辑的助手可以为开发者节省大量时间和认知负担. 根本的挑战在于, LLM 缺乏直接的文件系统访问权限, 他们必须通过专门的工具来描述预期的修改, 然后这些工具或 API 解释指令并尝试执行, LLM 的描述与文件系统状态之间的这种交接是常见的问题来源. 使用 GitHub Coplit、Aider、RooCode 或 Cursor 等工具的用户可能已经观察到这些问题: 编辑器无法找到正确的插入点、缩进不正确, 或者工具最终请求手动应用. ...

这篇文件介绍如何使用 Python 制作一个基础的 AI 编程助手 Minimal AI Coding Agent 下面是一个 AI Coding Agent 至少需要的功能 Chat loop 对话循环 Call an LLM 调用大语言模型 Add tools to call 增加工具调用 Handle tool request 处理工具调用请求 Step 1: Chat Loop 首先, 聊天循环一直循环等待用户输入, Python 的 “input” 方法可以获取用户输入 print("Type q to quit") while True: user_message = input("You: ") if user_message == "q": break ai_message = f"You said {user_message}... so insightful" print(ai_message) 目前主流的 LLM 都是无状态的, 所以需要我们手动的去管理对话上下文, 这里使用一个 fake_ai 函数模拟真实的 LLM 调用, 并包含 role 和 content 内容 ...

这篇文章旨在介绍 Python 中常用的提示词组织方式 f-string 使用 f 字符串填充变量得到提示词 def get_prompt(query: str) -> list[dict]: SYSTEM_PROMPT = f"""... ... 多行提示词, 也可以填充变量 """ USER_PROMPT = f"""INPUT: {query} .... """ return [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": USER_PROMPT}, ] 这种方法实现简单, 速度快, 但是: 多行字符串由于填充变量的需要, 需写在函数内, 导致代码格式混乱 # 实际上, 多行字符串还可以这样实现, 但也不太时候提示词太多的时候, 但这样代码格式会更加优雅 system_prompt = ( f"你是一名{role}负责...\n" f"具体规则:\n" f"1. ...." f"2. ...." ) 上面这种方法会将多行字符串合并, 注意不要加逗号, 不然就变成元组了 通过代码构造提示词, 任何修改都需要修改代码, 扩展性差 string.Template 使用 Python 元素字符串模板 SYSTEM_PROMPT = string.Template("""你是一名$role 多行提示词... """) USER_PROMPT = string.Template("""INPUT: $query """) def get_prompt(role: str, query: str) -> list[dict]: system_prompt = SYSTEM_PROMPT.subtitute(role="助手") user_prompt = USER_PROMPT.subtitute(query="问题...") return [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt}, ] 使用模板字符串, 模板则不必写在函数内, 且模板字符串可以选择替换部分变量, 使用 .safe_substitute()方法传入一个字典, 例如 {"query": "问题..."}, 对没有传入的变量解析为 $var 对比 f-string, 模板字符串更加灵活, 且可以只传入部分值 ...