鲁大师估计到头了
LINUX DO - 热门话题 (RSS)



一个驱动检测竟然还要升级会员

47 个帖子 - 29 位参与者

阅读完整话题

解封了，唯一的一个3级没有了，再也不相信抽奖了，越出名的大佬越不能信。
LINUX DO - 热门话题 (RSS)



可怜的我，天天拼命人工点击到3级 这样废了

48 个帖子 - 43 位参与者

阅读完整话题

抽奖-是你的童年回忆吗？
LINUX DO - 热门话题 (RSS)

这次给大家抽童年回忆，合金弹头合集版，这是你的童年回忆吗？我小时候都是在街机厅玩的。

正文如下：

Steam链接： [Steam 上的 METAL SLUG Bundle]

(Steam 上的 METAL SLUG Bundle)



**奖品详情：合金弹头合集版（合金弹头1+合金弹头X+合金弹头3） ( METAL SLUG Bundle) Steam激活CDKEY

领奖要求： 中奖者需自备国区Steam账号！！！
中奖人数： 1人

发放形式： 使用[LINUX DO 抽奖程序]抽奖，中奖后以本站私信发送CDKEY形式发放

参与方式： 在下方对此贴进行回复。

截至时间： 2025-08-20 下午5点（北京时间）

注意事项：

— 中奖者需自备国区Steam账号。
— 每位用户仅允许参与一次。
— 请确保您已开启L站私信功能，以便接收中奖通知。
— 中奖者将在中奖结果公布后3日内收到站内私信通知。收到私信后，请在3日内回复确认领取奖品。逾期则视为放弃，奖品将顺延至下一楼层回复的参与者。
— 所有规则及抽奖结果由活动发起人最终解释。

61 个帖子 - 61 位参与者

阅读完整话题

【Gemini的奉承】一步步被Gemini夸得鼻涕冒泡
LINUX DO - 热门话题 (RSS)



看完回答只想说：“我怎么这么屌”

Gemini

24 个帖子 - 23 位参与者

阅读完整话题

‌授人以鱼不如授人以渔：怎么写完美的prompt - part 2
LINUX DO - 热门话题 (RSS)

授人以鱼不如授人以渔：怎么写完美的prompt

搞七捻三

续接上回
中文版本
https://github.com/KuekHaoYang/AI-Prompt-Protocols/blob/main/高级提示词工程权威指南：系统架构与对话动态.pdf
英文版本
https://github.com/KuekHaoYang/AI-Prompt-Protocols/blob/main/A%20Definitive%20Guide%20to%20A...

OK,上一次只是整本书的part 1，让你们消化消化，这次我就放整本书了

英文版本

Architecting Intelligence: A Definitive Guide to the Art and Science of Elite Prompt Engineering.pdf (1.8 MB)

github.com



Architecting%20Intelligence%3A%20A%20Definitive%20Guide%20to%20the%20Art%20and%20Science%20of%20Elite%20Prompt%20Engineering.pdf

中文版本

构建智能：顶级提示词工程的艺术与科学权威指南.pdf (3.6 MB)

github.com



%E6%9E%84%E5%BB%BA%E6%99%BA%E8%83%BD%EF%BC%9A%E9%A1%B6%E7%BA%A7%E6%8F%90%E7%A4%BA%E8%AF%8D%E5%B7%A5%E7%A8%8B%E7%9A%84%E8%89%BA%E6%9C%AF%E4%B8%8E%E7%A7%91%E5%AD%A6%E6%9D%83%E5%A8%81%E6%8C%87%E5%8D%97.pdf

markdown

中文版本

github.com/KuekHaoYang/AI-Prompt-Protocols

%E6%9E%84%E5%BB%BA%E6%99%BA%E8%83%BD%EF%BC%9A%E9%A1%B6%E7%BA%A7%E6%8F%90%E7%A4%BA%E8%AF%8D%E5%B7%A5%E7%A8%8B%E7%9A%84%E8%89%BA%E6%9C%AF%E4%B8%8E%E7%A7%91%E5%AD%A6%E6%9D%83%E5%A8%81%E6%8C%87%E5%8D%97.md

main

# 构建智能：顶级提示词工程的艺术与科学权威指南

# 第一章：提示词的哲学：人机协作导论

## 1.1 一场新对话的黎明

在人工智能飞速发展的版图上，大语言模型（LLM）已然成为一股变革性的力量，它是一种有潜力重新定义生产力、创造力和问题解决方式的工具。然而，这些模型蕴含的巨大能量，往往受限于一个关键因素：它们接收到的沟通质量。这，便是提示词工程这门学科的起点。

**提示词**（Prompt），最简单的形式，就是你提供给 AI 模型的指令、问题或输入。它是每一次互动的催化剂，是每一个生成的句子、图像或代码的起点。因此，**提示词工程**（Prompt Engineering），就是一门设计这些输入，以引导 AI 模型产出精确、可靠、高价值输出的艺术和科学。

我们必须澄清“工程”这个词。这门学科无需任何软件开发或数据科学背景。从根本上说，它是一门沟通的学科。你可以把它想象成学习如何与你那位能力超凡的新同事沟通。你的意图表达得越清晰、越具体、越有情境，AI 就越能准确地执行你的构想。输入的质量不仅影响输出，它甚至决定了输出。

本指南将为你掌握这种新形式的对话提供一个全面的框架。它建立在这样一种哲学之上：与 AI 互动，并非简单的问答交易，而是关乎于构建对话、设计行为，并锻造一种能同时提升人与机器能力的协作伙伴关系。

## 1.2 AI 是协作者，而非神谕

一个常见的误解是将大语言模型（LLM）视为无所不知的神谕——一个装着所有答案的魔法盒子，只等一个正确的问题来开启。这种看法局限了它的潜能。一个更强大、更准确的心智模型是，将 AI 视作一位技能无限，但初来乍到的助理。他读完了整个互联网，但对你、你的目标或当前任务没有任何具体背景。并且，每段对话一结束，他就会立刻失忆。

这位助理是一个强大的预测引擎。当你提供一个提示词时，LLM 并非像人类一样“理解”你的请求。相反，它会进行复杂的统计分析，根据其在训练中学到的大量模式，预测最有可能跟在你输入之后的一系列词语（或“tokens”）。你的提示词为这个预测设定了初始条件，它创建了一个起点，AI 从这一点出发，规划出最可能的路径。



此文件已被截断。 显示原始文件

英文版本

github.com/KuekHaoYang/AI-Prompt-Protocols

Architecting%20Intelligence%3A%20A%20Definitive%20Guide%20to%20the%20Art%20and%20Science%20of%20Elite%20Prompt%20Engineering.md

main...

View original post

‌我回来了！很抱歉各位道友，抽奖继续！加大筹码。8点开奖。
LINUX DO - 热门话题 (RSS)

https://linux.do/t/topic/857996

上周被钓鱼成功！被封了，很尴尬，大家以我为戒，不要违反论坛版规。

抽奖话题今晚8点就开奖，我再外加5个名额，马上就该帖子规则。

再次感谢 @Xavier9896 @lhDream 两位道友资助的升仙令，一会一并抽取。

36 个帖子 - 32 位参与者

阅读完整话题

感谢始皇的不杀之恩
LINUX DO - 热门话题 (RSS)

第一次参与抽奖看始皇发的啥也没看

进去就是复制粘贴

就被钓鱼执法了

没刷L站这几天难受死我了

我！胡汉三！又回来！！！！



77 个帖子 - 35 位参与者

阅读完整话题

‌研究 PRD / SPEC / BMAD，我们在追求什么
LINUX DO - 热门话题 (RSS)

研究 PRD / SPEC / BMAD，我们在追求什么

公众号地址 欢迎关注 https://mp.weixin.qq.com/s/p1hnI3omEEp_OiMvoiegFQ

背景与动机
真实场景大概是这样：今天即兴 vibe 了一下午，撸出一个 MVP；之后因为上下文长度受限，只能开新 session 接着做。新 session 里，模型对你之前的决策、边界、坑点一无所知，你只能一点点把“做过什么、为什么这么做、这次要改什么”重新喂进去。重复沟通、反复铺垫，效率直线下降。

后来大家发现：把上次的重要内容“总结/压缩”进文档，下次开发时直接 @ 引用，就能把上下文串起来。这个朴素做法，后来被称为“上下文工程”。之后很多方法（SPEC、PRD、BMAD、工作流、角色分工）都是在它之上演进的外衣。

我们关心的目标只有一个：让交付“质量可控”，过程“人工干预极少”，最好能“无人化”。

SPEC、PRD、BMAD：外衣不同，本质相同

— SPEC 把需求拆成 requirements/design/tasks，看起来很专业，但经常把上下文碾得过碎，线性长闭环导致问题在集成/验收才爆。更糟的是，在一段时间里模型“降智”，就很难产出质量可控的代码。
— PRD 回到“做事用”的文档：目标、范围、验收口径清楚，能直接驱动实现与测试；不追求厚度，追求可执行。
— BMAD 引入角色做分工：PO 写 PRD、Architect 写 system architecture、SM 写 sprint plan，Dev/QA 执行与门控。实质仍是上下文工程：把关键口径写入对应产物，串好接力。

我看到很多人花大量时间研究角色与工作流，结果是在换着方式做同一件事。思想不变：只用 PRD 也能产出可控的代码。更值得投入的是：如何保证整条交付链路质量可控，从需求到开发到测试到验收到上线的“少人干预，尽量无人化”。

什么是“上下文工程”（Context Engineering）
定义：围绕一次开发/调用时需要的上下文，做获取、筛选、组织、压缩与治理的系统化方法，让输出可控、可复现。

为什么重要：模型能力接近时，谁的上下文更准、更干净、布局更好，谁的效果就稳定（更低幻觉、更高成功率、更低时延与成本）。

关键组成：

— 需求与评测：任务定义、成功指标、离线/在线评测集合。
— 上下文素材：系统约束、用户意图、few-shot、工具 schema/结果、知识片段、会话状态。
— 检索与重排：BM25/向量/混合索引，查询改写，多跳检索，重排器。
— 组织与布局：信息分区与顺序（约束→工具→证据→示例→任务）、结构化格式、引用标注。
— 压缩与预算：摘要、去重、语义压缩、token 预算策略。
— 路由与编排：模型/提示选择，Agent/工具调用，回退与重试。
— 安全与合规：过滤、输出约束、工具白名单。
— 观测与版本：日志回放、A/B、数据血缘、模板/索引版本。

和 Prompt 工程的区别：Prompt 工程偏“写好指令与示例”；上下文工程覆盖“检索、布局、压缩、路由、评测与治理”的全链路，是更大的系统工程。

常见范式：

— RAG 2.0：查询改写 → 多索引检索 → 重排 → 证据去冗压缩 → 生成（带引用）。
— 工具增强：函数调用/工具执行 → 结果注入上下文 → 继续推理。
— 记忆体系：短期会话缓存 + 长期任务档案（可检索）。
— 模板分层：系统指令模块化 + 任务槽位化 + 证据段落。

关键指标：任务成功率、可溯源性、幻觉率、引用命中率、延迟、成本、token 利用率、召回/覆盖@k。

落地清单（速用）：

— 定义任务与评测集合（黄金问答/任务脚本）；
— 建索引：清洗→分块→向量/关键词混合索引→重排；
— 设计模板：明确区块顺序与输出 JSON Schema；
— 压缩策略：检索后做去重与摘要；
— 上线观测：日志+回放+A/B，版本化迭代检索与模板。

示意模板（简化）：

# system
你是{角色}。必须遵守：{约束...}

# task
{用户意图/指令}

# tools (schema & results)
{可调用工具定义/最近一次调用结果}

# grounding (top-k)
{检索证据片段+来源}

# examples
{few-shot 边界对齐}

# output
请只输出符合此 JSON Schema 的结果：{schema}

PRD 一条路，也能跑出可控交付
PRD 要“轻但能用”，信息以可执行为准：

— Goals、FR/NFR、Epic、Stories、AC、Out of Scope（删赘述）。
— 最少集：

— 文件路径/函数签名
— API 请求/响应与错误码
— 数据迁移与回滚脚本
— 配置项与灰度开关
— 日志字段、监控指标与报警阈值

两道门槛：

— 需求确认 ≥90 分（歧义打光且获批准）才开工；
— 规格必须“可执行”（缺路径/签名/示例/迁移/观测的不算规格）。

流水线：确认 → 规格 → 实现 → 评审 → 测试 → 验收。评审只看：需求符合、集成可行、代码不作恶（安全/性能）、测试覆盖足够。未达标，退回。

角色是分工，不是目的

— PO → 产出 PRD：目标/范围/AC 清楚，Out of Scope 明确。
— Architect → 产出 system architecture：运行时、依赖、集成边界、迁移/回滚、观测前置。
— SM → 产出 sprint plan：按“可见产物”的垂直切片排顺序。
— Dev/QA → 执行与门控：变更清单、测试记录、质量门槛达标再过。

复杂项目、多人协作时再引角色/并行流水线，用“各自的小上下文”减少污染与负担；别为了热闹而热闹。

小例子：邀请码有效期
口径先定：

— 起算点：首次使用，不是创建；
— 时区：统一 UTC，边界秒判定清楚；
— 历史兼容：存量无有效期如何处置；
— 错误返回：错误码与 HTTP 状态码映射；
— 回退策略：迁移/回滚、灰度与开关。

规格到动作：

SQL（迁移与回滚各一份）：

ALTER TABLE invitations ADD COLUMN expires_at TIMESTAMP NULL;
-- 回滚：ALTER TABLE invitations DROP COLUMN expires_at;

验证函数：

// 首次使用时写 first_used_at，过期返回标准错误
function validateInvitation(code: string): ValidationResult

API：

POST /invitations/validate
响应（过期）：{ "error": "INVITATION_EXPIRED", "code": 4001 }

观测：

— 指标：过期命中次数、拒绝率；
— 日志：校验入参、判定结论、错误码；
— 告警：拒绝率异常阈值。

测试优先级：

— 边界秒；
— 历史无有效期兼容；
— 配置变更生效路径；
— 错误码与 HTTP 状态码一致性。

反模式清单

— 为了 Prompt 而 Prompt：词很满，事很空；
— 角色崇拜：沉迷设定，忽略可执行与可验证；
— 文档堆砌：没有路径/签名/迁移/观测的内容，都是噪音；
— 上下文泛洪：不清理、不切片，质量衰减、成本上升；
— 只跑快乐路径：边界与失败不测，后期集中爆雷。

落地路线

— 选一个小需求（如“邀请码有效期”）完整跑完：确认 → 规格 → 实现 → 测试；
— 给核心模块补 CLAUDE.md（索引化），确保可 @ 引用到“短事实”；
— 把 CI 门槛立起来：覆盖率、静态扫描、关键用例不过线不合并；
— 复杂时再引 BMAD 分工与并行流水线，让各段上下文更小、更干净。

结语
研究 PRD、SPEC、BMAD，不是为了流程更精致，而是为了把“上下文”这件事做稳，最后得到“质量可控、人工干预极少、可走向无人化”的交付。先把上下文工程打牢，剩下的是自动化与规模化。

19 个帖子 - 11 位参与者

阅读完整话题

我知道超越大水哥的方法了，速来 百分百成功 很快就能超越 ｜ 怎么屏蔽大水哥
LINUX DO - 热门话题 (RSS)

（以下纯乐子 纯玩笑）

只要我们保证每个帖子大水哥都没办法点赞评论是不是就可以让他掉级？

理论成立，我们来实践

— 每个人发帖子都屏蔽他
— 把大水哥丢到荒岛上 100 小时
— 让大水哥家断电断网
— 我们以后都不发帖子了（bushi）

我给大家提供了四个方法，希望大佬能实现！

大家集思广益，一起变水

85 个帖子 - 18 位参与者

阅读完整话题

‌xxx大学图书馆模拟器
LINUX DO - 热门话题 (RSS)

今天别人分享的，感觉挺有趣。话说做这个的大佬在我们L站吗

小毛毛熊 | 个人网站

17 个帖子 - 17 位参与者

阅读完整话题

感觉这两年思维越来越僵硬了
LINUX DO - 热门话题 (RSS)

如题，遇到问题能想到的变通渠道越来越少，简单的问题也逐渐公式化，脱离常见问题后经常有点不知所措。不知道是工作太久了，还是学习太少，有点难绷

60 个帖子 - 29 位参与者

阅读完整话题