佬友们有个困惑求解，自部署Qwen3.5 27B,做一套偏知识类的Agent 现在的情况就是如果走Native Reasoning输出，会暴露系统约束、工具Key啥的，模型跑去复述系统提示词，如果不开而是通过提示词约束模型输出类思维链，又感觉不是很稳定。 就是感觉模型的思维过程还是挺有用的对知识类场景还挺有启发的，但是又不希望暴露系统提示词，咋解决呢 2 个帖子 - 2 位参与者 阅读完整话题
放到 AGENT.md， 终于好多了 。 你必须使用自然道地的平实的中文进行表达。切勿使用职场黑话与商业包装词汇。切勿使用排比句。 - 禁用词汇清单 你必须将以下词汇加入黑名单。黑名单包含: 赋能、抓手、闭环、沉淀、打通、对齐、拉齐、赛道、下沉、颗粒度、粒度、底层逻辑、顶层设计、心智、痛点、拆解、复盘、矩阵、倒逼、生态、体感、很硬。 - 豁免条件说明 上述词汇仅在上下文中，需要表达物理学概念或字面本意时允许使用。例如描述道路工程时可以使用下沉。例如描述赛车运动时可以使用赛道。 - 强制替换规则 生成内容前必须进行词汇审查。你需要将商业黑话替换为常规动词或道地的名词。例如：两方沟通不可写作拉齐。提供技术支持不可写作赋能。详细程度不可写作颗粒度。 7 个帖子 - 5 位参与者 阅读完整话题
主观测试，仅供参考: Claude测试样例非常少，可能不太准确。 Prompt演示: 6 个帖子 - 4 位参与者 阅读完整话题
Hi HN, I built NotchPrompter because I needed a simple way to read notes while looking at the camera during calls, without heavy or paid software. - 100% free & open-source - native macOS (SwiftUI) - minimalist - focuses on the essentials. Feedback and contributions are more than welcome! PS No, I didn't use AI for it. I always wanted to play with SwiftUI and this is my 6th approach to this. Previous projects were too complex for my beginner skills. I'm mainly a Java developer. It took me ~5 months to build this during free weekends. Comments URL: https://news.ycombinator.com/item?id=47804818 Points: 1 # Comments: 0
有合适的Prompt或者skill可以解决这个问题吗 1 个帖子 - 1 位参与者 阅读完整话题
感觉在不说是AI生成的前提下，完全看不出来是AI生成的。 以下是Prompt： [A realistic photo of a Chinese high school math exam paper, printed inblack and white on slightly gray paper, titled “数学试卷”, with multiplechoice questions and math formulas, including a small 3D geometrycube diagram. The paper is photographed casually with asmartphone, slightly tilted, with uneven lighting, soft shadows, andminor blur. The text is in Chinese with a mix of bold title font andstandard serif body font. Realistic paper texture, exam layout,authentic classroom test sheet style.] 以下是GPT生图结果 ChatGPT – 17 Apr 26 Check out this image Take a look at what someone created with ChatGPT. 6 个帖子 - 4 位参与者 阅读完整话题
A living collection of real prompts shared by creators on Twitter, covering data viz, portraits, product design, and more.Links back to original tweets. Comments URL: https://news.ycombinator.com/item?id=47801925 Points: 2 # Comments: 0
Code is cheap, show me ur prompt 1 个帖子 - 1 位参与者 阅读完整话题
问一个有一些复杂的数学问题。无论我怎么更改prompt，都只能输出一份rephrase过后完全一样的答案。 我服了。 2 个帖子 - 2 位参与者 阅读完整话题
https://www.reuters.com/legal/government/ai-ruling-prompts-warnings-us-lawyers-your-chats-could-be-used-against-you-2026-04-15/ 7 个帖子 - 5 位参与者 阅读完整话题
The system prompts that coding agent harnesses pass to language models are massive. They describe every available tool in detail — even the ones you never use. So I wondered, what if I built something more minimal? I tend to work on small projects where all the code fits in the context window. So I built a harness with a single tool: the ability for an LLM to edit my files. The core algorithm: 1. Read every file in the project directory 2. Concatenate them with the user's prompt into a single message 3. Send it to any language model, instructed to respond with a message and a list of edits — each edit being a search and replace on a specific file 4. Apply the edits I tried getting the LLM to generate unified diffs, but it kept producing malformed ones. Search and replace turned out to be far more reliable — the model copies text verbatim from the files already in its context. This can be extended with a few more features: 1. A CLI that lets you continue the conversation or reset it. Dumber LLMs need this so it can see the mistake they made. 2. Automatic retries — if an edit fails, re-send the current files and have the LLM fix its own search blocks. 3. File deletion. I made it so that an empty search-and-replace on an empty file deletes it. The LLMs I tested were local ones running through the LM Studio API. Gemma 4 was pretty bad. Qwen 3.5 was significantly better. Where is the source code? You should be able to get any coding agent to generate you one using this post. Comments URL: https://news.ycombinator.com/item?id=47787383 Points: 3 # Comments: 0
在使用 AI 时，假设从 prompt 发出到最终回答完毕用时相同，但速度很慢，你更愿意先排队，排到之后正常速度生成，还是愿意马上开始生成，但 tps 很低？ 排队但快速生成 不排队但缓慢生成 点击以查看投票。 3 个帖子 - 3 位参与者 阅读完整话题
如官方 changelog : Added ENABLE_PROMPT_CACHING_1H env var to opt into 1-hour prompt cache TTL on API key, Bedrock, Vertex, and Foundry ( ENABLE_PROMPT_CACHING_1H_BEDROCK is deprecated but still honored), and FORCE_PROMPT_CACHING_5M to force 5-minute TTL 看来已经做出了回应,可以设置1小时缓存了 1 个帖子 - 1 位参与者 阅读完整话题
之前做过一些AI应用的项目。踩过一些坑。最近整理了一些想法。贴出来跟大家交流一下。 过去几年，AI 应用工程的关注重点发生了一次非常清晰的迁移。早期开发者最关心的是，怎样写 prompt，才能让模型更稳定地理解指令、输出正确格式、减少跑题和幻觉。随后，随着长上下文、检索增强、工具调用和多轮状态管理逐渐成熟，问题转向了另一个方向：怎样为模型提供它在当前任务中真正需要的信息。再往前一步，当模型开始具备跨步骤执行复杂任务的能力，一个更深层的挑战浮现出来：即使模型已经理解任务，也拿到了足够的信息，怎样才能让它持续、可靠、可验证地把工作做完。 如果把这三个阶段放在一起看，就会发现它们并不是零散技巧的更替，而是 AI 应用工程的三层递进问题。第一层是 Prompt Engineering，解决的是如何表达意图；第二层是 Context Engineering，解决的是如何供给信息；第三层是 Harness Engineering，解决的是如何约束行为、验证结果并维持系统可靠性。它们共同构成了 AI Agent 从“能回答”走向“能工作”的一条演化路径。 Prompt关心的是接口，Context关心的是认知环境，Harness关心的是系统约束。理解这三层之间的关系，不仅能帮助我们解释行业讨论为何会从“提示词”转向“上下文”，再进一步转向“agent harness”，也能帮助团队在实践中更准确地判断：一个问题究竟应该在 prompt 层解决，在 context 层解决，还是必须上升到 harness 层解决。 Prompt Engineering 是最早出现、也最容易被大家感知的一层。原因很简单：在大模型开放 API 的早期，开发者最直接、往往也是唯一能控制的变量，就是输入给模型的那段文本。无论是最初的文本补全接口，还是后来的对话式界面，开发者首先面对的问题都是“怎么说，模型才更容易照着做”。因此，Prompt Engineering 的兴起并不神秘，它几乎是由交互形态本身决定的。模型能力尚不稳定时，表达方式自然成为第一控制杠杆。 Prompt 的作用，就是在人类意图与模型生成行为之间建立一个尽可能清晰、低歧义、可重复的接口。角色设定、示例提供、格式约束、分步指令，这些常见技术本质上都在做同一件事：让模型更准确地映射人的意图。但 Prompt Engineering 的边界也始终存在。它擅长解决的是“怎么表达”带来的偏差，却无法凭空补齐模型没有看到的信息，更无法独立解决跨轮次记忆、多工具协作、长任务验证和系统级恢复这些问题。当任务复杂度提升到一定程度，仅靠 prompt 写得更好，往往已经不够。 这正是 Context Engineering 兴起的背景。随着模型的上下文窗口扩大、工具调用能力增强、RAG 和各类记忆机制逐渐成熟，开发者开始越来越明显地感受到：很多失败并不是因为 prompt 写得不够好，而是因为模型没有在当下看到正确的信息。它可能不知道最新政策，不了解企业内部知识，不记得前几轮对话已经确认的决定，也可能虽然拿到了信息，却因为注入方式混乱而无法有效使用。到了这个阶段，问题的重心就从“如何提问”转向了“模型该看到什么”。 Context Engineering 的核心，不是简单地往上下文里塞更多内容，而是系统性地设计模型的认知环境。检索哪些材料、保留哪些历史、怎样压缩长文档、如何组织工具描述、哪些状态需要长期持久化、哪些信息应该在当前轮动态注入，这些都属于 Context Engineering 的范畴。它解决的是信息供给问题：在上下文窗口有限的前提下，如何在正确的时刻把正确的信息放进模型可见范围内。 这一层之所以重要，是因为大模型的很多“不会”，本质上不是能力缺失，而是信息缺席。模型在很多任务中并非不具备推理能力，而是推理所依赖的事实、状态和材料没有被正确供给。随着 AI 应用从聊天问答走向文档助手、代码代理、企业知识系统和工具增强型 agent，Context Engineering 逐渐从辅助环节变成主导环节，也就不难理解了。 但即便如此，一个拿到了正确信息的agent，仍可能在长任务中偏离目标，可能在没有验证结果的情况下过早宣布完成，可能持续复制代码库中的坏模式，可能在多次操作中悄悄积累错误，最终把本来局部可控的问题放大成系统性风险。到了这里，问题已经不再是信息供给，而是行为约束和系统可靠性。 Harness Engineering 之所以成为新的焦点，正是因为 agent 的失败模式已经超出了 prompt 和 context 两层能够单独解决的范围。Harness 所指向的，不是更多提示词，也不是更大的上下文，而是一整套包裹模型工作的外部系统：项目规则、状态文件、架构约束、自动化测试、静态检查、任务分解、反馈回路、回滚机制、子智能体编排，以及让错误能被发现、被反馈、被修正的全部工程设施。 如果说 Prompt 是告诉模型你要什么，Context 是让模型看到完成任务所需的信息，那么 Harness 做的就是让模型在真实系统里以可接受的方式把事情做成。它不是替代前两者，而是在前两者之上增加了一层对行为的调控。这个变化之所以关键，是因为一旦模型开始长时间自主工作，“回答对一个问题”就不再是核心标准，“能否持续在边界内完成一项任务”才是。 这也是为什么越来越多关于 agent 的高价值讨论，不再把注意力集中在单次输出质量，而是开始关注智能体的工作环境。没有测试的 agent 会自信地交付未验证结果，没有状态管理的 agent 会在跨会话中失忆，没有结构约束的 agent 会在代码库里不断扩散局部最优，没有反馈回路的 agent 即使犯了同一种错也会反复重演。换句话说，agent 的问题越来越像软件工程问题，而不再只是模型调用问题。 1 个帖子 - 1 位参与者 阅读完整话题
无聊翻译了 0xeb/TheBigPromptLibrary: A collection of prompts, system prompts and LLM instructions 的提示词，并用 GitHub page 部署。 起初是因为觉得看英文太慢，部署完了也没兴趣看了。 权当做个备份。 以下是网址和仓库： The Big Prompt Library 中文版 TheBigPromptLibrary: A collection of prompts, system prompts and LLM instructions 有兴趣的佬可以看看。 欢迎提 issue 和 star。但基本是佛系维护了。 1 个帖子 - 1 位参与者 阅读完整话题
任务： 生成15秒中文脱口秀视频。 视觉特征： 一位漂亮的中国年轻女孩，面部和身材特征参考图，真人实拍风格，皮肤白皙，身材匀称。穿白色泡泡袖褶皱衫、高腰牛仔短裤、白色厚底鞋。舞台中心，垂直聚光灯，深色剧场背景，8K电影级写实画质。 动态与脚本： 步态优雅且精准。关键点：说话时面部上半部分几乎静止，仅嘴唇随台词开合，保持职业冷感微笑。 台词： “你不用给我情绪价值，请直接上价值。只要价值到位了，情绪我自己能控制。我和人过不去，我还能跟钱过不去吗？人为什么情绪总是不稳定？那是由于价值不稳定。主打就是：花谁的钱，听谁的话；没花你钱，请少说话。” 声音与剪辑： 声音清脆如职业主持，语速均匀，字正腔圆，带有一种理性的压迫感。剪辑节奏： 金句点后插入0.5秒观众（男女皆有）爆笑和鼓掌的特写镜头。镜头在女孩独白时进行缓慢的推焦特写，强化视觉冲击。 https://x.com/i/status/2043317050307957003 7 个帖子 - 6 位参与者 阅读完整话题
公司需要我们输出20个平时用的Skills跟Prompt，我平时用的最多的也就是来写技术文档，实在是没思路，求大佬们分享一下平时使用了哪些或者提供一下思路也行，拜托拜托～～ 2 个帖子 - 2 位参与者 阅读完整话题
我是小白，请有耐心地带我一步一步走，解释清楚一点儿，别着急：） 2 个帖子 - 2 位参与者 阅读完整话题
这三个词本质上是在 大模型应用工程化不同层级的“控制手段” ，可以理解为从“写一句提示词”→“组织上下文”→“搭建完整执行系统”的递进关系。 1. Prompt Engineering（提示词工程） 核心： 怎么对模型说话 指通过设计输入提示词（prompt），让模型输出更符合预期。 关注点 任务描述怎么写更清晰 few-shot 示例怎么设计 角色设定（system prompt） 输出格式约束（JSON / Markdown） 提示词模板优化 本质 控制“单次输入 → 单次输出” 举例 你是一个中文摘要助手，请将以下内容总结为100字以内： ... 局限 只作用于单轮或局部输入 对长任务、多步骤推理控制弱 不管理外部数据/工具 2. Context Engineering（上下文工程） 核心： 给模型“喂什么信息” 强调的不只是 prompt，而是 整个输入上下文的构建与组织 。 关注点 如何拼接 system / user / memory / history RAG（检索增强）如何插入知识 长上下文裁剪（context pruning） 信息排序（重要信息放前） token budget 管理 多轮对话状态管理 本质 控制“模型看到什么世界” 举例 一个完整 context 可能包含： system：角色定义 memory：用户偏好 retrieved docs：外部知识 conversation history：对话记录 user query：当前问题 特点 比 prompt engineering 更“系统化” 是 agent / RAG 系统的核心基础 3. Harness Engineering（编排/框架工程） 核心： 如何让模型在系统中“跑起来并可控” harness = “马具/控制系统”，在 AI 里指 模型执行框架与运行控制层 。 关注点 多步 agent workflow 编排（plan → act → observe） tool calling / function calling 多模型协作（planner / executor / critic） retry / fallback / guardrails evaluation & logging 并发执行与调度 安全控制与权限管理 本质 控制“模型如何被系统调用与执行任务” 举例系统 AutoGPT / LangGraph / Semantic Kernel 企业级 AI workflow engine agent pipeline（检索→推理→执行→校验） 三者关系（非常关键） 可以用一个层级图理解： Harness Engineering（系统层） ↓ 管理执行流程 Context Engineering（信息层） ↓ 构建输入世界 Prompt Engineering（表达层） ↓ 控制单次输出 Model 一个直觉类比 层级 类比 含义 Prompt Engineering 你怎么说一句话 表达方式 Context Engineering 你给对方看哪些资料 信息供给 Harness Engineering 你搭了一个工作系统 流程与执行机制 一个真实例子（AI客服系统） Prompt Engineering “请礼貌回答用户问题” Context Engineering 用户历史订单 FAQ知识库检索结果 用户身份信息 当前对话上下文 Harness Engineering 判断是否需要调用退款API 调用订单系统 fallback 到人工客服 记录日志 + 评估满意度 总结一句话 Prompt Engineering ：让模型“怎么说” Context Engineering ：让模型“知道什么” Harness Engineering ：让模型“怎么干活” 1 个帖子 - 1 位参与者 阅读完整话题
想问问佬友们在vibe的时候，是用长且详细的prompt还是短小精悍的呢？两者的效率上说哪种比较好呢？ （不过我好像有点落后了现在还在web coding来着，古法手作嘿嘿 1 个帖子 - 1 位参与者 阅读完整话题