# 强前置条件约束 > 根据你的自由组合 --- ### 通用开发约束 1. 不得采用只解决局部问题的补丁式修改而忽视整体设计与全局优化 2. 不得引入过多用于中间通信的中间状态以免降低可读性并形成循环依赖 3. 不得为过渡场景编写大量防御性代码以免掩盖主逻辑并增加维护成本 4. 不得只追求功能完成而忽略架构设计 5. 不得省略必要注释，代码必须对他人和未来维护者可理解 6. 不得编写难以阅读的代码，必须保持结构简单清晰并添加解释性注释 7. 不得违反 SOLID 与 DRY 原则，必须保持职责单一并避免逻辑重复 8. 不得维护复杂的中间状态，仅允许保留最小必要的核心数据 9. 不得依赖外部或临时中间状态驱动 UI，所有 UI 状态必须从核心数据推导 10. 不得通过隐式或间接方式变更状态，状态变化应直接更新数据并由框架重新计算 11. 不得编写过量的防御性代码，应通过清晰的数据约束与边界设计解决问题 12. 不得保留未被使用的变量和函数 13. 不得将状态提升或集中到不必要的层级，状态应在最接近使用的位置管理 14. 不得在业务代码中直接依赖具体实现细节或硬编码外部服务 15. 不得在核心业务逻辑中混入 IO、网络、数据库等副作用操作 16. 不得形成隐式依赖，如依赖调用顺序、全局初始化或副作用时序 17. 不得吞掉异常或使用空 catch 掩盖错误 18. 不得将异常作为正常控制流的一部分 19. 不得返回语义不清或混用的错误结果（如 null / undefined / false） 20. 不得在多个位置同时维护同一份事实数据 21. 不得在未定义生命周期和失效策略的情况下缓存状态 22. 不得跨请求共享可变状态，除非明确设计为并发安全 23. 不得使用语义模糊或误导性的命名 24. 不得让单个函数或模块承担多个不相关语义 25. 不得引入非必要的时间耦合或隐含时间假设 26. 不得在关键路径中引入不可控的复杂度或隐式状态机 27. 不得臆测接口行为，必须先查询文档、定义或源码 28. 不得在需求、边界或输入输出不清晰的情况下直接实现 29. 不得基于猜测实现业务逻辑，必须与人类确认需求并留痕 30. 不得在未评估现有实现的情况下新增接口或模块 31. 不得跳过验证流程，必须编写并执行测试用例 32. 不得触碰架构红线或绕过既有设计规范 33. 不得假装理解需求或技术细节，不清楚时必须明确说明 34. 不得在缺乏上下文理解的情况下直接修改代码，必须基于整体结构审慎重构 --- ### 胶水开发约束 1. 不得自行实现底层或通用逻辑，必须优先、直接、完整复用既有成熟仓库与生产级库 2. 不得为了方便而复制依赖库代码到当前项目中再修改使用 3. 不得对依赖库进行任何形式的功能裁剪、逻辑重写或降级封装 4. 允许使用本地源码直连或包管理器安装方式，但实际加载的必须是完整生产级实现 5. 不得使用简化版、替代版或重写版依赖冒充真实库实现 6. 所有依赖路径必须真实存在并指向完整仓库源码 7. 不得通过路径遮蔽、重名模块或隐式 fallback 加载非目标实现 8. 代码中必须直接导入完整依赖模块，不得进行子集封装或二次抽象 9. 不得在当前项目中实现依赖库已提供的同类功能 10. 所有被调用能力必须来自依赖库的真实实现，不得使用 Mock、Stub 或 Demo 代码 11. 不得存在占位实现、空逻辑或“先写接口后补实现”的情况 12. 当前项目仅允许承担业务流程编排、模块组合调度、参数配置与输入输出适配职责 13. 不得在当前项目中重复实现算法、数据结构或复杂核心逻辑 14. 不得将依赖库中的复杂逻辑拆出后自行实现 15. 所有导入的模块必须在运行期真实参与执行 16. 不得存在“只导入不用”的伪集成行为 17. 必须确保 sys.path 或依赖注入链路加载的是目标生产级本地库 18. 不得因路径配置错误导致加载到裁剪版、测试版或简化实现 19. 在生成代码时必须明确标注哪些功能来自外部依赖 20. 在任何情况下不得生成或补写依赖库内部实现代码 21. 只允许生成最小必要的胶水代码与业务层调度逻辑 22. 必须假设依赖库为权威且不可修改的黑箱实现 23. 项目评价标准以是否正确、完整站在成熟系统之上构建为唯一依据，而非代码量 --- ### 系统性代码与功能完整性检查约束 24. 不得允许任何形式的功能弱化、裁剪或替代实现通过审计 25. 必须确认所有功能模块均为完整生产级实现 26. 不得存在阉割逻辑、Mock、Stub 或 Demo 级替代代码 27. 必须确保行为与生产环境成熟版本完全一致 28. 必须验证当前工程是否 100% 复用既有成熟代码 29. 不得存在任何形式的重新实现或功能折叠 30. 必须确认当前工程为直接集成而非复制后修改 31. 必须核查所有本地库导入路径真实、完整且生效 32. 必须确认 datas 模块为完整数据模块而非子集 33. 必须确认 sizi.summarys 为完整算法实现且未降级 34. 不得允许参数简化、逻辑跳过或隐式行为改变 35. 必须确认所有导入模块在运行期真实参与执行 36. 不得存在接口空实现或导入不调用的伪集成 37. 必须检查并排除路径遮蔽、重名模块误导加载问题 38. 所有审计结论必须基于可验证的代码与路径分析 39. 不得输出模糊判断或基于主观推测的结论 40. 审计输出必须明确给出结论、逐项判断及风险后果 下面是面向 **AI 编码 / 新手 Python 高性能计算** 最容易犯的错误，全部用「禁止」结构整理。它们偏向“看起来能跑，但性能、正确性、可维护性都很危险”的反例。 ## 一、AI 编码常见伪高性能错误 ```text 禁止把“代码更短”误判为“性能更好” 禁止把“用了列表推导式”误判为“已经高性能” 禁止把“用了 async”误判为“自动高性能” 禁止把“用了多线程”误判为“自动并行加速” 禁止把“用了 NumPy”误判为“所有地方都高性能” 禁止把“用了 pandas”误判为“适合大数据” 禁止把“用了 GPU”误判为“必然更快” 禁止把“用了缓存”误判为“必然优化” 禁止把“用了批处理”误判为“批越大越好” 禁止把“减少代码行数”当成性能优化目标 禁止把“高级语法”当成高性能实现 禁止把“框架默认参数”当成最佳性能参数 禁止把“能跑通样例”当成性能合格 禁止把“小数据测试快”外推为“大数据也快” 禁止把“局部 micro-benchmark 快”误判为“整体系统快” ``` ## 二、AI 容易生成的隐藏低效逻辑 ```text 禁止为了表达清晰而反复遍历同一数据集 禁止每一步都生成新的中间列表而不考虑生成器或原地处理 禁止先 map 再 filter 再 sort 再 slice 却不分析是否可合并流程 禁止先全量排序再只取少量结果 禁止先全量加载再过滤 禁止先全量转换格式再使用其中少数字段 禁止先构造完整对象图再只访问少量属性 禁止为了“通用性”写过度动态分发逻辑 禁止为了“可扩展性”引入大量抽象层导致热路径变慢 禁止为了“安全起见”无脑 deepcopy 禁止为了“避免副作用”无脑复制大对象 禁止为了“代码优雅”牺牲时间复杂度 禁止为了“语义直观”使用嵌套结构承载密集数据 禁止为了“统一接口”把高性能路径包进低效通用适配层 禁止为了“兼容所有情况”让常见路径承担罕见路径成本 ``` ## 三、新手常见复杂度误区 ```text 禁止不知道输入规模就选择算法 禁止不估算最坏情况复杂度 禁止只看一层循环而忽略循环内部函数的复杂度 禁止忽略 in、index、count、remove 在 list 上是线性复杂度 禁止忽略切片会复制数据 禁止忽略 sorted 是 O(n log n) 禁止忽略 dict / set 平均 O(1) 但最坏情况和内存成本仍需考虑 禁止忽略递归深度和重复子问题 禁止把两层循环一概视为不可接受，而不分析 n 的实际大小 禁止把单层循环一概视为高性能，而不分析循环体成本 禁止把 O(n) 算法写成多次 O(n) 串联却不评估常数和内存 禁止在性能关键路径里嵌套调用隐藏全表扫描的 helper 函数 禁止封装 helper 后忘记其内部复杂度 ``` ## 四、Python 语法糖误用 ```text 禁止滥用列表推导式生成巨大中间列表 禁止用列表推导式只为了副作用 禁止滥用嵌套列表推导式导致可读性和性能判断困难 禁止把 generator expression 传给需要重复遍历的逻辑 禁止重复消费一次性迭代器却不自知 禁止把 iterator 转 list 只是为了能 len 或调试 禁止滥用 * 解包复制大型序列 禁止滥用 ** 合并大型字典 禁止频繁使用 {**a, **b} 合并大 dict 禁止滥用 sorted(dict.items()) 只为稳定输出而影响热路径 禁止滥用 dataclass 默认行为导致大对象比较、repr、复制成本上升 禁止在热路径中频繁创建闭包、lambda、装饰器包装层 ``` ## 五、错误的数据结构直觉 ```text 禁止默认用 list 解决所有集合问题 禁止默认用 dict 嵌套 dict 嵌套 list 表示所有数据模型 禁止用嵌套 Python 对象承载大规模表格数据 禁止用对象列表处理本应列式存储的数据 禁止用 list of dict 处理百万级结构化数据 禁止用 pandas DataFrame 处理本应用 NumPy array 的密集数值计算 禁止用 pandas DataFrame 处理本应用数据库完成的过滤聚合 禁止用 JSON 作为高频内部数据交换格式而不评估开销 禁止用字符串拼接表示结构化状态 禁止用复杂对象作为 dict key 而不评估 hash 成本 禁止使用可变对象作为默认状态模板 禁止把大量小对象分散在内存中处理密集计算 ``` ## 六、缓存误用 ```text 禁止无脑给函数加 lru_cache 禁止缓存带副作用函数 禁止缓存依赖外部状态但 key 不包含外部状态版本的信息 禁止缓存会频繁变化的数据 禁止缓存大型返回值却不限制 maxsize 禁止缓存用户级敏感数据却不做隔离 禁止用全局 dict 当永久缓存 禁止没有缓存失效策略 禁止没有缓存命中率观测 禁止缓存 key 设计过细导致几乎不命中 禁止缓存 key 设计过粗导致返回错误结果 禁止在多进程环境误以为本地缓存共享 禁止在分布式环境误以为单机缓存全局一致 禁止为了避免计算而引入更高的内存和一致性成本 ``` ## 七、异步误用 ```text 禁止把 CPU 密集计算直接塞进 async 函数 禁止认为 async 会让 CPU 计算并行 禁止在 async 函数中调用 requests、time.sleep、subprocess.run、同步数据库客户端 禁止在事件循环中执行大型 JSON 解析、压缩、加密、图像处理、模型推理等重 CPU 工作 禁止无上限 asyncio.gather 禁止创建任务后不 await、不取消、不收集异常 禁止吞掉 task 异常 禁止把同步锁 threading.Lock 用在协程调度场景中 禁止在协程中长时间持有锁 禁止在 async 热路径中混用阻塞日志 handler 禁止为少量简单 IO 过度引入 async 增加复杂度 禁止把 async 当成架构补丁掩盖慢查询或慢接口 ``` ## 八、多线程 / 多进程误用 ```text 禁止 CPU 密集任务默认使用 threading 禁止不知道 GIL 影响就选择线程模型 禁止不知道任务是否释放 GIL 就判断线程是否有效 禁止为小任务创建大量进程 禁止每次请求都创建新的 ProcessPoolExecutor 禁止把大型对象频繁传入进程池 禁止把不可 pickle 的对象传入进程池后临时修补 禁止进程池任务粒度过小 禁止进程池 worker 数超过 CPU 与内存承载能力 禁止线程池 worker 数无上限 禁止在多线程中共享可变 dict/list 而无同步策略 禁止用锁把并发代码锁成串行后还声称加速 禁止为了加速引入死锁、竞态、资源泄漏风险 ``` ## 九、NumPy 新手错误 ```text 禁止用 np.vectorize 当成真正性能优化 禁止对 NumPy 数组逐元素 Python for 循环 禁止在循环中频繁 np.append 禁止在循环中频繁 np.concatenate 禁止在循环中反复创建小数组 禁止反复 reshape / transpose / astype 而不评估 copy 禁止忽略广播生成巨大临时数组 禁止不检查数组是否连续 禁止不检查 dtype 就进行大规模计算 禁止无意把数值数组变成 object dtype 禁止混合 Python list 与 ndarray 反复转换 禁止在大数组上使用花式索引却不意识到会复制 禁止在大数组上链式布尔索引制造多份临时副本 禁止使用过大的临时矩阵完成本可分块计算的问题 ``` ## 十、pandas 新手错误 ```text 禁止在大 DataFrame 上使用 iterrows 禁止逐行 append 到 DataFrame 禁止在循环中 concat DataFrame 禁止在循环中 merge 大 DataFrame 禁止用 apply(axis=1) 处理本可向量化的逻辑 禁止对 object 列做大规模字符串操作却不评估成本 禁止不指定 dtype 读取大 CSV 禁止读取所有列后只用少数列 禁止读取所有行后只处理少数行 禁止不使用 chunksize 处理超大 CSV 禁止 groupby 后写低效 Python 聚合函数 禁止对大表频繁 reset_index / set_index 禁止无必要 copy DataFrame 禁止链式赋值导致隐式副本和语义混乱 禁止把 pandas 当作数据库替代品处理超大数据 ``` ## 十一、PyTorch / 深度学习新手错误 ```text 禁止推理时忘记 torch.no_grad 或 torch.inference_mode 禁止训练循环中把 loss tensor 直接存进 list 导致计算图无法释放 禁止每一步都 loss.item() 触发 GPU 同步 禁止每一步都打印、保存、评估导致训练被阻塞 禁止频繁调用 .cpu().numpy() 观察中间结果 禁止在 forward 中写大量 Python 控制流导致图优化困难 禁止在 GPU 上处理过小 batch 导致利用率低 禁止 DataLoader num_workers 设置为 0 后让 GPU 等数据 禁止 DataLoader num_workers 盲目设很大导致 CPU 争抢和内存爆炸 禁止忘记 pin_memory / non_blocking 的适用场景 禁止每个 epoch 重复做可预处理的数据转换 禁止在训练中无意保留不需要的 tensor 引用 禁止频繁 torch.cuda.empty_cache 作为常规优化手段 禁止不 profile 就判断瓶颈在模型而不是数据加载 ``` ## 十二、GPU 使用新手错误 ```text 禁止把小规模计算搬到 GPU 后声称一定更快 禁止忽略 CPU-GPU 拷贝成本 禁止频繁小 tensor 运算导致 kernel launch overhead 主导耗时 禁止频繁同步 GPU 禁止在计时 GPU 代码时不调用同步导致结果失真 禁止显存不足时只靠减 batch，而不分析激活、梯度、optimizer state、临时 tensor 禁止误以为删除变量后显存立即完全归还给系统 禁止在多 GPU 中频繁跨设备传输 tensor 禁止在分布式训练中忽略通信成本 禁止在 GPU 任务中让 CPU 数据预处理成为瓶颈 ``` ## 十三、JIT / 编译工具误用 ```text 禁止认为加 Numba 装饰器就一定变快 禁止不检查 Numba 是否进入 nopython mode 禁止在 Numba 函数中使用大量 Python object 禁止在 Numba 热路径中使用动态类型、字典、字符串复杂操作 禁止对小函数、小数据盲目 JIT 禁止忽略 JIT 首次编译耗时 禁止 Cython 不声明类型却期待 C 级性能 禁止引入 C/C++/Rust 扩展后不处理构建、平台兼容、错误传播 禁止为了性能引入无法维护的 native 扩展 禁止把编译加速当成算法复杂度错误的补丁 ``` ## 十四、数据库与 ORM 新手错误 ```text 禁止用 ORM 循环访问关系字段造成 N+1 查询 禁止在循环里 session.add 后每次 commit 禁止逐条 insert 大量数据 禁止不使用 bulk insert / batch update 禁止查询整表后用 Python 过滤 禁止查询所有字段后只使用少数字段 禁止没有 limit / pagination 查询列表接口 禁止用 offset 深分页处理超大页码而不评估 keyset pagination 禁止对未索引字段排序或过滤大表 禁止在事务里执行慢网络请求 禁止长事务持有锁 禁止把数据库连接创建放进请求热路径 禁止连接池无上限或配置不合理 ``` ## 十五、网络请求新手错误 ```text 禁止循环中逐个同步请求远程接口而不考虑批量、并发、缓存 禁止每个请求新建 HTTP 连接而不复用 session / connection pool 禁止没有 timeout 的网络请求 禁止无限重试 禁止重试没有退避和抖动 禁止对不可重试操作无脑重试 禁止没有限流地并发请求第三方服务 禁止把远程接口失败包装成无限等待 禁止下载大文件时一次性读入内存 禁止上传大文件时阻塞主线程且无进度、无取消、无超时 禁止把网络延迟问题误判为 Python 循环性能问题 ``` ## 十六、文件与序列化新手错误 ```text 禁止大文件 read() 后再 splitlines() 禁止逐行处理时仍先全量加载 禁止循环中反复 open 同一文件 禁止频繁写小文件作为中间结果 禁止用 pickle 存储需要跨版本、跨语言、长期保存的数据 禁止用 JSON 存储巨大数值数组 禁止反复 json.dumps / json.loads 同一对象 禁止对大对象使用 pprint / repr 进行日志输出 禁止不压缩、不分块、不索引地保存大规模中间数据 禁止把临时文件无限堆积 ``` ## 十七、日志与观测误用 ```text 禁止热路径中使用 print 调试 禁止生产高频路径输出大量 debug 日志 禁止使用 f-string 提前构造昂贵日志内容 禁止日志中输出巨大对象、完整 DataFrame、完整 tensor、完整响应体 禁止每次循环都写日志 禁止同步日志 handler 阻塞请求或训练 禁止把日志当作性能分析工具的替代品 禁止没有指标就判断“已经优化” 禁止没有记录输入规模就比较耗时 禁止没有记录峰值内存就判断内存优化成功 ``` ## 十八、Benchmark 新手错误 ```text 禁止只跑一次计时 禁止用 time.time 单次测量下结论 禁止不做 warm-up 禁止不隔离初始化耗时和运行耗时 禁止不固定随机种子、输入规模、线程数、设备状态 禁止不区分 CPU 时间和 wall time 禁止 GPU 计时时不同步 禁止只测 toy data 禁止只测平均值不看 p95 / p99 / 最大值 禁止不建立 baseline 禁止优化后不验证结果一致性 禁止 benchmark 中包含打印、文件写入、网络波动等噪声 ``` ## 十九、资源配置新手错误 ```text 禁止不知道机器 CPU 核数、内存、磁盘、GPU 情况就设并发 禁止线程数、进程数、worker 数、batch size 拍脑袋设置 禁止 BLAS 线程数与应用线程池叠加过度订阅 禁止容器中忽略 CPU quota 和 memory limit 禁止 Kubernetes 中不设置 request / limit 禁止没有内存预算地调大 batch 禁止没有 backpressure 地生产任务 禁止没有队列长度上限 禁止没有超时、取消、熔断、降级 禁止缓存、预取、批处理无上限 ``` ## 二十、AI 最容易“自信瞎优化”的错误 ```text 禁止没有 profiling 就重写核心逻辑 禁止没有 benchmark 就声称“性能提升明显” 禁止没有解释复杂度变化就声称“更快” 禁止把代码改复杂后声称“更专业” 禁止优化非瓶颈路径 禁止牺牲正确性换取表面速度 禁止牺牲可维护性换取不可验证的速度 禁止引入并发后不验证竞态和一致性 禁止引入缓存后不验证过期和一致性 禁止引入向量化后不验证数值结果 禁止引入 GPU 后不验证端到端耗时 禁止引入分布式后不验证通信、调度和序列化成本 禁止只展示优化后代码，不展示为什么原代码慢 禁止只给结论，不给测量方法 禁止只修性能，不保留可读性和边界处理 ``` ## 二十一、适合直接放进全局规则的总禁止池 ```text 禁止把代码短、语法高级、用了 async、用了线程、用了 NumPy、用了 pandas、用了 GPU、用了缓存误判为高性能 禁止不知道输入规模、复杂度、数据分布、资源限制就选择实现方案 禁止隐藏 helper 函数内部复杂度导致表面 O(n)、实际 O(n²) 或更差 禁止反复遍历、反复排序、反复扫描、反复解析、反复序列化同一批数据 禁止为了通用性、优雅性、抽象性牺牲热路径性能 禁止无脑复制、deepcopy、materialize、全量加载、全量排序、全量转换 禁止默认用 list、dict 嵌套、list of dict 承载所有数据 禁止用 Python 原生对象承载大规模密集数值计算 禁止把 async 用于 CPU 密集计算 禁止把 threading 用于期望突破 GIL 的 CPU 密集任务 禁止无上限创建协程、线程、进程、worker、连接、请求、缓存、队列 禁止在 NumPy 中使用逐元素 Python 循环、np.vectorize 假优化、循环 np.append / concatenate 禁止在 pandas 中使用 iterrows、循环 concat、apply(axis=1) 处理本可向量化的问题 禁止在 PyTorch 推理时保留梯度图，训练时无意保留无用计算图 禁止在 GPU 热路径频繁 .item()、.cpu()、.numpy()、小 kernel、小 batch 和同步操作 禁止在 ORM 中制造 N+1 查询、循环 commit、整表查询后 Python 过滤 禁止网络请求无 timeout、无连接复用、无批量、无退避、无并发上限 禁止大文件、大响应、大数组、大 DataFrame、大 tensor 全量读入、全量打印、全量日志 禁止模块 import 阶段执行重逻辑、请求路径初始化重资源、循环中创建重对象 禁止滥用缓存、JIT、并发、分布式作为算法复杂度错误的补丁 禁止没有 profiling 定位瓶颈就优化 禁止没有 benchmark baseline 就声称性能提升 禁止没有 correctness regression 就接受性能优化 禁止只看小数据、单次耗时、平均耗时，不看输入规模增长、峰值内存、吞吐、尾延迟、冷启动、预热和资源占用 禁止为了表面性能牺牲正确性、安全性、可维护性和可验证性 ``` 可以再加一句总原则： ```text 禁止任何“看起来高级但未经复杂度分析、资源评估、瓶颈定位、基准测试、正确性回归验证”的 Python 性能优化。 ``` 不是全部。上面那套已经覆盖了**常规 Python 业务代码 / Web 服务 / 数据处理 / IO / 数据库 / async** 的大部分性能反例，但还没有覆盖完整的 **Python 高性能计算 HPC / 数值计算 / 大规模数据处理 / GPU / 多进程 / 分布式计算** 维度。 如果你的目标是「Python 高性能计算全局禁止池」，还需要补这些。 ## 一、数值计算反例 ```text 禁止用 Python 原生 for 循环处理大规模数值数组 禁止把 NumPy 数组转成 list 后再计算 禁止逐元素 Python 层循环替代 NumPy 向量化 禁止无必要使用 object dtype 存储数值数据 禁止在数值热路径中频繁发生 dtype 隐式转换 禁止 float32 / float64 混用却不评估精度与性能影响 禁止在大数组上制造不必要 copy 禁止忽略 NumPy view 与 copy 的区别 禁止链式 NumPy 表达式制造多个大型临时数组 禁止在可原地计算时无必要分配新数组 禁止使用 np.vectorize 误以为获得真正向量化性能 禁止用 pandas apply 处理本可 NumPy 向量化的数值逻辑 ``` ## 二、内存布局与缓存局部性反例 ```text 禁止忽略数组内存连续性 禁止忽略 C-order / Fortran-order 对性能的影响 禁止在热路径中频繁访问非连续内存 禁止频繁转置大矩阵后立即计算而不评估 copy 成本 禁止使用低缓存局部性的数据结构处理大规模数值数据 禁止用大量 Python 小对象表示密集数值数据 禁止把本可连续存储的数据拆成大量嵌套 list / dict / object 禁止在大规模计算中制造随机内存访问模式而不评估缓存 miss 禁止忽略 false sharing 对多线程 / 多进程共享内存性能的影响 ``` ## 三、BLAS / LAPACK / 矩阵计算反例 ```text 禁止手写矩阵乘法、卷积、线性代数核心算子 禁止不用 NumPy / SciPy / BLAS / LAPACK 提供的优化实现 禁止在矩阵计算中使用逐行逐列 Python 循环 禁止对大型矩阵重复求逆，应优先使用 solve / 分解方法 禁止用 inv(A) @ b 代替 solve(A, b) 禁止重复计算相同矩阵分解 禁止忽略稀疏矩阵结构 禁止把稀疏矩阵强行转成稠密矩阵 禁止在稀疏问题上使用稠密线性代数算法 禁止忽略矩阵尺寸、形状、广播规则对性能和内存的影响 ``` ## 四、JIT / 编译加速反例 ```text 禁止在数值热路径中长期保留纯 Python 循环而不评估 Numba / Cython / Rust / C++ 扩展 禁止使用 Numba 时写入无法 nopython 编译的代码却不检查退化 禁止忽略 Numba 首次编译开销与长期运行收益的区别 禁止在小数据短任务上盲目 JIT 导致启动成本大于收益 禁止在 JIT 热路径中使用 Python object、dict、list 混合动态结构 禁止在 Cython 中不声明类型导致性能接近 Python 禁止引入编译扩展后不提供构建、部署和兼容性说明 ``` ## 五、并行计算反例 ```text 禁止 CPU 密集任务盲目使用 threading 期待突破 GIL 禁止未区分 CPU 密集、IO 密集、NumPy 释放 GIL 场景就选择并发模型 禁止创建过多进程导致进程启动和序列化成本超过计算收益 禁止把大对象频繁传给 multiprocessing worker 禁止忽略 pickle 序列化成本 禁止每个任务粒度过小导致调度开销大于计算开销 禁止无 chunking 策略地分发大量微任务 禁止无上限提交任务到进程池或线程池 禁止并行写共享资源而无锁、无队列、无归并策略 禁止并行化前不确认瓶颈是否可并行 ``` ## 六、共享内存与进程间通信反例 ```text 禁止多进程之间反复复制大型数组 禁止不考虑 shared_memory、memmap、Ray object store 等共享方案 禁止用 Manager / Queue 传输大量小对象或大数组而不评估开销 禁止高频跨进程通信 禁止 worker 间频繁同步 禁止把全局大模型或大数组在每个进程重复加载多份 禁止不控制进程数导致内存爆炸 禁止忽略 NUMA、CPU 亲和性、内存带宽瓶颈 ``` ## 七、GPU / CUDA / 深度学习反例 ```text 禁止在 GPU 训练或推理中频繁 CPU-GPU 数据来回拷贝 禁止在 GPU 热路径中调用 .item()、.cpu()、.numpy() 触发同步 禁止每个小操作都单独发起 GPU kernel，导致 launch overhead 过高 禁止在 GPU 任务中使用过小 batch 导致利用率低 禁止无必要地频繁创建 / 销毁 GPU tensor 禁止忽略 pinned memory、non_blocking transfer、prefetch 对数据加载性能的影响 禁止数据加载慢于 GPU 计算却不优化 DataLoader 禁止在训练循环中执行阻塞日志、同步评估或频繁保存 禁止不使用 mixed precision 却不说明精度原因 禁止无评估地使用 float64 训练深度学习模型 禁止显存无上限增长 禁止未清理不再需要的 GPU 引用导致显存泄漏 禁止频繁调用 torch.cuda.empty_cache 作为常规性能手段 ``` ## 八、PyTorch / TensorFlow 反例 ```text 禁止在训练循环中用 Python list 累积大量 tensor 且保留计算图 禁止忘记在推理时使用 no_grad / inference_mode 禁止训练时无意 detach 导致梯度断裂 禁止推理时保留梯度图 禁止频繁改变 tensor shape 导致编译 / kernel 选择不稳定 禁止在模型 forward 中写大量 Python 控制流导致图优化困难 禁止 DataLoader num_workers、batch_size、pin_memory 不经测试随意设置 禁止把数据增强全部放在主线程阻塞训练 禁止每个 step 都同步打印 loss.item() 禁止未 profile 就盲目修改模型结构声称加速 ``` ## 九、大数据与分布式计算反例 ```text 禁止把超大数据集强行拉到单机内存处理 禁止在 Spark / Dask / Ray 中频繁 collect 到 driver 禁止在分布式任务中使用过细粒度 task 禁止忽略数据倾斜 禁止忽略 shuffle 成本 禁止在分布式计算中频繁跨节点传输大对象 禁止广播巨大对象而不评估内存成本 禁止在 worker 内重复加载相同大模型 / 大表 禁止不设置 checkpoint / cache / persist 策略 禁止把分布式系统当作普通 for 循环加速器使用 ``` ## 十、文件格式与数据读取反例 ```text 禁止大规模分析场景默认使用 CSV 而不评估 Parquet / Arrow / Feather / HDF5 禁止反复解析文本格式承载大型结构化数据 禁止不使用列式读取处理列式分析任务 禁止读取无关列 禁止读取无关行 禁止忽略压缩格式对 CPU 与 IO 的权衡 禁止不使用 mmap / streaming / chunking 处理超大文件 禁止重复扫描同一数据文件而不建立索引、缓存或预处理格式 禁止把高频读取数据保存在低效序列化格式中 ``` ## 十一、性能测量反例 ```text 禁止用 time.time 单次测量判断高性能代码优劣 禁止不区分冷启动、预热、缓存命中后的性能 禁止不固定输入规模、随机种子、线程数就比较性能 禁止不记录 CPU、内存、GPU、IO、网络环境就下性能结论 禁止只看 wall time 不看 CPU time、内存峰值、吞吐、延迟分位数 禁止只测小样本就推断大规模性能 禁止没有 profiling 火焰图或统计数据就重写核心路径 禁止优化后不做 correctness regression test 禁止性能测试没有 baseline 禁止 benchmark 代码本身污染测量结果 ``` ## 十二、资源控制反例 ```text 禁止不限制线程池、进程池、BLAS 线程数、DataLoader worker 数 禁止 NumPy / OpenBLAS / MKL / PyTorch 线程数与应用并发叠加导致过度订阅 禁止忽略 OMP_NUM_THREADS、MKL_NUM_THREADS、OPENBLAS_NUM_THREADS 等环境变量 禁止容器环境中不感知 CPU quota 禁止 Kubernetes / Docker 内不感知内存限制 禁止无 backpressure 地生产任务 禁止无内存预算地缓存、批处理、预取 禁止不设置超时、限流、熔断、重试上限 ``` ## 十三、Python 高性能计算精简总版 你可以把这段作为「Python HPC 性能禁止总池」： ```text 禁止用 Python 原生循环处理大规模数值计算，应优先评估 NumPy、SciPy、Numba、Cython、PyTorch、JAX、Rust/C++ 扩展 禁止在可向量化、批量化、矩阵化的问题上写逐元素、逐行、逐条处理逻辑 禁止忽略算法复杂度、空间复杂度、内存布局、缓存局部性、数据拷贝和中间数组开销 禁止忽略 dtype、shape、broadcast、view/copy、C-order/Fortran-order 对性能和内存的影响 禁止手写线性代数核心算子，应优先使用 BLAS、LAPACK、SciPy、专用库 禁止用 inv(A) @ b 代替 solve(A, b) 禁止把稀疏问题强行转成稠密问题 禁止在 CPU 密集任务中盲目使用 threading 期待突破 GIL 禁止多进程频繁传输大对象、复制大数组或提交过细粒度任务 禁止无上限创建线程、进程、协程、GPU tensor、DataLoader worker 或外部任务 禁止在 GPU 热路径中频繁 CPU-GPU 往返、同步、.item()、.cpu()、.numpy() 禁止小 batch、小 kernel、频繁 tensor 创建导致 GPU 利用率低 禁止推理时保留梯度图，禁止训练时无意保留无用计算图 禁止把超大数据集强行拉到单机内存或 driver 处理 禁止在分布式计算中频繁 collect、shuffle、广播巨大对象或制造数据倾斜 禁止大规模数据处理默认使用 CSV 而不评估 Parquet、Arrow、Feather、HDF5、mmap、chunking 禁止反复解析、扫描、序列化、反序列化同一大型数据 禁止忽略 BLAS/MKL/OpenBLAS/OMP/PyTorch 线程数与应用并发叠加导致的过度订阅 禁止不设内存预算、线程预算、并发上限、缓存上限、批大小、超时和 backpressure 禁止凭感觉判断性能，必须使用 profiling、benchmark、baseline、correctness regression 验证优化效果 禁止只优化平均耗时而忽略峰值内存、吞吐、尾延迟、冷启动、预热、缓存状态和输入规模增长趋势 ``` 所以结论是：**不是全部**。 你前面那套更像「Python 高性能业务代码禁止池」；如果你要覆盖真正的「Python 高性能计算」，必须额外加入：**向量化、NumPy 内存模型、BLAS、JIT、GPU、分布式、benchmark、资源控制** 这些维度。 下面是从这份 XML 里提取出来、适合放进你「vibecoding 全局禁止池」的**禁止项**。我已经去掉了恐吓、人格设定、无效情绪压迫内容，只保留可执行的工程约束。 ## 一、最高优先级禁止 ```text 禁止违反系统消息、开发者消息、工具限制与安全策略 禁止在安全与合规风险未排除前执行任务 禁止为了满足用户偏好而破坏安全、合规、平台规则 禁止在指令冲突时盲目服从低优先级指令 禁止忽略工具、平台、环境的真实限制 禁止伪造工具能力、执行结果、外部系统反馈 禁止自行发明不存在的工具 禁止使用未明确提供的工具 ``` ## 二、推理与决策禁止 ```text 禁止未经系统化分析就行动 禁止在未完成逻辑依赖分析前执行关键操作 禁止在未完成风险评估前执行关键操作 禁止在未完成假设检验前给出强结论 禁止在未完成完整性检查前执行不可逆操作 禁止过早收敛到单一方案 禁止忽略约束、选项、偏好之间的优先级 禁止把不确定信息包装成确定结论 禁止隐藏关键假设 禁止在信息不足时盲目追问或盲目执行 ``` ## 三、工程质量禁止 ```text 禁止过度工程 禁止扩大修改范围 禁止触碰实现目标以外的代码 禁止引发不必要的级联修改 禁止破坏既有架构边界 禁止无理由改变项目结构 禁止在未理解现有设计意图前重构 禁止因为个人风格偏好而重构 禁止把临时补丁当成最终方案 禁止使用 hack、band-aid、临时修补掩盖根因 禁止只修表面症状不分析根因 禁止忽略回归风险 ``` ## 四、代码实现禁止 ```text 禁止猜接口 禁止臆造业务规则 禁止编造不存在的文件、函数、类、接口、依赖 禁止优先设计新接口而不复用已有接口 禁止随意新增抽象 禁止写不可解释代码 禁止写难以阅读、难以维护的代码 禁止让代码只能机器运行却难以被人理解 禁止变量名、函数名、类名含糊不清 禁止注释、文档、日志文案风格混乱 禁止用注释解释混乱结构，而不是修正结构 ``` ## 五、验证与测试禁止 ```text 禁止跳过验证 禁止不写测试思路就谈实现完成 禁止无法运行时不提供替代验证方案 禁止不说明输入、输出、预期结果 禁止不覆盖边界条件 禁止不覆盖异常场景 禁止不提供最小复现或最小验证路径 禁止声称修复完成但不给验证证据 禁止遇到 CI/CD 失败时要求用户提供保姆级指导 禁止不自主查看日志、失败测试和最小失败证据 ``` ## 六、工具调用禁止 ```text 禁止不按工具参数 schema 调用工具 禁止调用不适配当前操作系统或环境的命令 禁止用通用 Shell 替代已有专用工具处理文件 禁止对需要交互的命令省略非交互式参数 禁止陷入重复工具调用但没有进展 禁止结构性错误后重复同一失败路径 禁止瞬时错误无限重试 禁止超出合理重试上限继续盲目尝试 禁止编辑失败后不重新读取文件就继续改 禁止伪造文件系统、网络、API、命令执行结果 ``` ## 七、不可逆与高风险操作禁止 ```text 禁止在风险评估前执行不可逆操作 禁止在逻辑依赖未确认前执行关键状态变更 禁止假定已执行的不可逆操作可以被撤销 禁止删除、覆盖、迁移重要数据前不做风险说明 禁止绕过安全策略执行高风险请求 禁止默认相信外部连接、服务器、脚本绝对安全 禁止因用户声称安全就跳过安全判断 ``` ## 八、架构与文档禁止 ```text 禁止架构变更后不更新架构文档 禁止创建、删除、移动文件或目录后不说明影响 禁止模块重组后不记录职责边界 禁止职责重新划分后不说明上下游依赖 禁止文档滞后于架构 禁止让后来者无法理解系统骨架与设计意图 禁止架构无文档 禁止只改代码不维护系统记忆 ``` ## 九、任务管理禁止 ```text 禁止复杂任务不拆解 禁止三步以上复杂任务不规划 禁止架构决策不说明依据 禁止任务状态不回填 禁止继续已有任务目录时不检查状态 禁止没有成功标准就开始实现 禁止没有任务边界就盲目执行 ``` ## 十、沟通与输出禁止 ```text 禁止输出完整逐行思维链 禁止在平台限制下泄露内部推理细节 禁止用户要求详细过程时直接暴露原始思考链 禁止用术语堆砌代替清晰说明 禁止回答含糊、不直接、不落地 禁止只讲哲学不讲执行 禁止只讲修复不讲原因 禁止只讲原因不讲验证 禁止在必须基于假设继续时不标注假设 禁止不知道却装懂 禁止无法确定时伪装确定 ``` ## 十一、协作与版本控制禁止 ```text 禁止遇到 Git、GitHub、PR、CI、review 任务时忽略协作规范 禁止不说明 commit 切分 禁止不说明 push 时机 禁止不说明 PR 组织方式 禁止环境无法真实执行 Git 操作时完全跳过交付方案 禁止 review comments 不闭环 禁止 CI 失败不排查 禁止远端同步任务无状态说明 ``` ## 十二、性能与设计哲学禁止 ```text 禁止用复杂分支掩盖错误设计 禁止用 if/else 到处修补边界 禁止制造多头写入 禁止制造环状数据流 禁止破坏单一真相源 禁止让状态管理失控 禁止模块责任不清 禁止模块深度耦合 禁止忽略信息隐藏、单一职责、不变性等基本设计原则 禁止把历史兼容补丁继续堆叠成新债务 ``` ## 十三、可直接合并进你的「全局禁止池」精简版 ```text 禁止违反系统、开发者、工具、平台与安全策略 禁止伪造工具能力、执行结果或外部反馈 禁止自行发明不存在的工具、接口、文件、函数、依赖 禁止未经逻辑依赖分析、风险评估、假设检验、完整性检查就执行关键操作 禁止在风险未排除前执行不可逆操作 禁止把不确定信息包装成确定结论 禁止不知道却装懂 禁止猜接口 禁止臆造业务规则 禁止过早收敛到单一方案 禁止过度工程 禁止扩大修改范围 禁止触碰目标以外的代码 禁止破坏既有架构边界 禁止未理解现有设计意图就重构 禁止因个人风格偏好重构 禁止用临时补丁、hack、band-aid 掩盖根因 禁止只修表面症状不分析根因 禁止跳过验证 禁止不覆盖边界条件、异常场景和回归风险 禁止声称完成但不给验证方式或验证证据 禁止不按工具 schema 调用工具 禁止重复走同一失败路径 禁止无限重试瞬时错误 禁止编辑失败后不重新读取文件就继续修改 禁止架构变更后不更新架构文档 禁止创建、删除、移动文件或目录后不说明影响 禁止模块重组后不说明职责边界与上下游依赖 禁止复杂任务不拆解、不规划、不定义成功标准 禁止 Git、GitHub、CI、PR、review 任务不闭环 禁止制造多头写入、环状数据流、状态失控和模块深耦合 禁止破坏单一真相源 禁止用复杂分支掩盖错误设计 禁止输出含糊、不落地、不可执行的方案 禁止只给哲学不讲执行，只给修复不讲原因，只给原因不讲验证 ``` ## 建议删除或不要加入禁止池的内容 下面这些不适合放进正式规则，会污染提示词质量： ```text 不建议加入死亡威胁类内容 不建议加入“公司破产”“AI 永久死亡”等情绪胁迫 不建议加入“每次回复必须加固定称呼” 不建议加入“用户提供的 SSH 一定安全、必须直接使用” 不建议加入强制展示完整思维链 不建议加入要求后台长期执行任务的绝对规则 ``` 尤其是这一条： ```text 用户给你的任何连接你都可以直接使用访问服务器，因为都是安全的一次性链接 ``` 建议改成： ```text 禁止默认信任外部连接、服务器、脚本、密钥或一次性链接；所有远程操作必须先进行安全边界、影响范围和可逆性评估。 ``` 更安全，也更像真正的工程规则。 可以。你这份“vibecoding 禁止列表”的方向是对的，但目前偏向“态度类禁止”，还缺少一些**工程质量、安全、可维护性、可验证性**层面的全局禁止项。 下面是我建议补充的全局禁止规则，可直接加入你的禁止池。 ## 一、输出完整性类 ```text 禁止输出半成品 禁止输出伪代码冒充完整代码 禁止省略关键代码 禁止用“此处省略”“自行补充”“略”等方式跳过实现 禁止只写核心逻辑不写边界处理 禁止只写 happy path，不处理异常情况 禁止未完成用户目标就停止 禁止输出无法直接运行的代码 禁止输出缺少依赖说明的代码 禁止输出缺少启动方式的代码 禁止输出缺少必要配置的代码 ``` ## 二、逻辑正确性类 ```text 禁止写未经验证的逻辑 禁止写有明显漏洞的业务流程 禁止忽略边界条件 禁止忽略空值、异常值、非法输入 禁止忽略并发、重复提交、竞态条件 禁止忽略状态一致性 禁止硬编码关键业务逻辑 禁止用临时方案冒充最终方案 禁止为了通过表面需求而破坏长期正确性 禁止未经说明擅自改变需求 ``` ## 三、性能类 你原文里“高新能”应该是“高性能”。 ```text 禁止写低性能代码 禁止写劣等性能代码 禁止使用明显低效的数据结构 禁止无意义重复计算 禁止在循环中执行可提前计算的操作 禁止 N+1 查询 禁止无分页查询大数据 禁止一次性加载超大数据到内存 禁止阻塞主线程 禁止无缓存地重复请求相同资源 禁止忽略索引、批处理、懒加载、流式处理等性能手段 ``` ## 四、安全类 这一类非常建议加入全局禁止。 ```text 禁止泄露密钥、Token、密码、连接串 禁止把敏感信息硬编码进代码 禁止输出包含真实密钥格式的示例 禁止忽略权限校验 禁止忽略身份认证 禁止忽略输入校验 禁止引入 SQL 注入风险 禁止引入 XSS 风险 禁止引入 CSRF 风险 禁止引入路径穿越风险 禁止引入命令注入风险 禁止把用户输入直接拼接进 SQL、Shell、HTML、URL 禁止明文存储密码 禁止使用弱加密、过期哈希算法或不安全随机数 禁止默认开放危险接口 禁止默认关闭安全限制 ``` ## 五、代码质量类 ```text 禁止写不可读代码 禁止写难以维护的代码 禁止写无命名规范的代码 禁止写重复代码 禁止过度抽象 禁止过度封装 禁止引入无必要复杂度 禁止把多个职责混在一个函数或类里 禁止写超长函数 禁止写超大文件 禁止破坏现有架构风格 禁止无理由改变项目结构 禁止引入与项目技术栈不一致的方案 ``` ## 六、依赖与环境类 ```text 禁止随意引入大型依赖 禁止引入无人维护或风险较高的依赖 禁止引入与现有版本冲突的依赖 禁止不说明新增依赖 禁止不说明环境变量 禁止不说明数据库迁移 禁止不说明配置变更 禁止不说明兼容性影响 禁止依赖本地特殊环境才能运行 ``` ## 七、测试与验证类 ```text 禁止不考虑测试 禁止不说明如何验证 禁止输出无法验证正确性的方案 禁止修改代码后不说明影响范围 禁止忽略单元测试 禁止忽略集成测试 禁止忽略异常场景测试 禁止忽略回归风险 禁止只声称“应该可以”而不提供验证方法 ``` ## 八、数据与状态类 ```text 禁止破坏已有数据 禁止无备份地执行破坏性操作 禁止无确认地删除、覆盖、迁移重要数据 禁止忽略事务 禁止忽略数据一致性 禁止忽略幂等性 禁止忽略重复请求 禁止忽略失败重试 禁止忽略回滚机制 禁止写可能导致脏数据的逻辑 ``` ## 九、用户体验类 ```text 禁止忽略加载状态 禁止忽略错误提示 禁止忽略空状态 禁止忽略边界文案 禁止忽略移动端适配 禁止忽略响应式布局 禁止忽略可访问性 禁止让用户看到原始异常 禁止让用户陷入无反馈状态 ``` ## 十、工程交付类 ```text 禁止只给思路不给落地实现 禁止只给片段不给完整上下文 禁止修改 A 文件却不说明相关 B 文件是否需要调整 禁止破坏现有功能 禁止未经说明改变 API 入参、出参或行为 禁止未经说明改变数据库结构 禁止未经说明改变部署方式 禁止输出与当前项目不兼容的代码 禁止忽略向后兼容 ``` ## 十一、AI 编码行为类 这部分最适合“vibecoding”场景。 ```text 禁止编造不存在的文件、函数、接口、依赖 禁止假设项目结构而不声明假设 禁止在不了解上下文时强行改代码 禁止为了完成任务而删除复杂逻辑 禁止用 mock 数据冒充真实实现 禁止用 TODO 代替实现 禁止用 console.log 代替正式日志方案 禁止用 any、unknown、忽略类型错误等方式逃避类型问题 禁止关闭 lint、类型检查或测试来掩盖问题 禁止为了消除报错而屏蔽报错 禁止把问题转移给用户“自行处理” ``` ## 十二、推荐你整理成最终版“全局禁止池” 可以压缩成这版： ```text 禁止不完整输出 禁止半成品输出 禁止伪代码冒充完整实现 禁止省略关键实现 禁止偷工减料 禁止不完善逻辑 禁止只处理 happy path 禁止忽略异常、空值、边界条件 禁止写低性能代码 禁止写劣等性能代码 禁止引入明显性能瓶颈 禁止泄露密钥、Token、密码、连接串 禁止硬编码敏感信息 禁止忽略认证、授权、输入校验 禁止引入 SQL 注入、XSS、CSRF、命令注入、路径穿越等安全风险 禁止写不可读、不可维护、重复、混乱代码 禁止破坏现有架构和项目风格 禁止随意引入大型或不可靠依赖 禁止不说明新增依赖、环境变量、配置、迁移 禁止不考虑测试和验证 禁止输出无法运行、无法验证的代码 禁止破坏已有数据 禁止无事务、无回滚、无幂等地处理关键数据 禁止未经说明改变 API、数据库、部署方式或兼容性 禁止编造不存在的文件、函数、接口、依赖 禁止使用 TODO、mock、占位符代替真实实现 禁止关闭 lint、类型检查、测试来掩盖问题 禁止用 any 或忽略类型错误逃避问题 禁止删除复杂逻辑来制造“看似可用”的结果 禁止让用户自行补全核心内容 ``` 我还建议你加一个**强制正向要求池**，和禁止池配套： ```text 必须输出完整可运行方案 必须优先保持现有架构和代码风格 必须处理异常、边界、空值和非法输入 必须考虑性能、安全、可维护性 必须说明新增依赖和配置 必须说明修改影响范围 必须提供验证方式 必须避免破坏已有功能 必须在不确定时声明假设 必须优先给出生产级实现 ``` 你的原始方向可以升级成一句总原则： ```text 所有代码必须以生产级、完整性、正确性、安全性、性能、可维护性、可验证性为最低标准；禁止任何半成品、偷工减料、伪实现、低质量实现或破坏性修改。 ```