区分代码现状与产品要求

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

开发者要求增加导出功能，你发现现有查询使用 LIMIT 100。教学材料中查询说明只写“列表首屏取 100 行”，没有导出权益规则；因此能确认当前列表行为，不能据此断言免费用户只能导出 100 行。

具体做法

先检查实现、文档与相关需求，记录可发现的技术事实。另列权威产品材料提供的约束，并指出尚未明确的事项。缺少导出上限时，先确定这是不是影响权限或完整性的必要决策；需要时集中询问，不用代码现状冒充业务要求。已有明确要求则引用，不重复提问。

反例

增加导出功能。查询里有 LIMIT 100，所以免费用户只能导出 100 行，按这个权益规则实现即可。

改进写法

根据上述查询与说明准备导出实现简报。分列技术事实、产品约束和待决定项：当前列表首屏取 100 行；材料没有说明导出权益上限。先检查是否还有维护的 PRD 或产品规则；若仍缺上限或权限约定，提出影响这次实现的具体问题，不从 LIMIT 100 推导收费权益，也不默默截断导出。已有明确规则时引用其位置。

为什么这样改

同一个 LIMIT 可能用于列表分页、性能保护或临时实现，并不能证明收费权益。分开事实和要求后，读者可以追溯一条限制的来源，也能看见目前还无法安全决定的行为。

如何验证

示意简报：事实—列表查询最多取 100 行，依据查询与首屏说明；产品约束—未提供导出上限；待决定—导出范围、权限与分页方式。

检查是否把未知保持为未知，是否错误新增“免费用户 100 行”的政策。若后来找到明确导出规则，应把它移到产品约束并引用，而不是仍列为待问。

适用边界

仓库中的维护版产品文档也可能提供权威规则，不能一概说业务信息无法从仓库获得。普通技术选择可依据证据推进；涉及权限、数据完整性或合同限制的未知不能靠便利的默认值决定。