Initial commit
This commit is contained in:
158
TASTE.md
Normal file
158
TASTE.md
Normal file
@@ -0,0 +1,158 @@
|
||||
# Taste Profile
|
||||
|
||||
这是用户当前有效 taste 的精炼视图。它是可修正的结论层,不是原始资料库;每条结论都应链接到 `learnings/` 中的证据。
|
||||
|
||||
## 使用约定
|
||||
|
||||
- `确认`:用户直接表达,或多份一致证据支持。
|
||||
- `暂定`:由有限示例推断,需要后续学习验证。
|
||||
- `有条件`:只在明确场景或约束下成立。
|
||||
- `已取代`:历史上成立,但已被后续偏好更新;保留用于解释演变。
|
||||
|
||||
应用某条偏好前,同时检查其适用范围。发生冲突时,优先使用更明确、更近期且场景更匹配的证据。
|
||||
|
||||
## 条目格式
|
||||
|
||||
画像按领域组织,每条偏好使用以下格式:
|
||||
|
||||
```markdown
|
||||
### 偏好标题
|
||||
|
||||
- 状态:确认 | 暂定 | 有条件 | 已取代
|
||||
- 适用范围:这条偏好影响哪些任务或场景
|
||||
- 规则:未来 Agent 应遵循的一句话规则
|
||||
- 证据:[学习记录](learnings/YYYY-MM-DD-NNN-short-title.md)
|
||||
- 边界:不适用场景、反例、冲突或未知项;没有则写“尚未发现”
|
||||
```
|
||||
|
||||
同一条偏好获得新证据时,优先更新现有条目并追加证据链接;只有规则或适用范围实质不同才新建条目。
|
||||
|
||||
## 当前画像
|
||||
|
||||
### 科研选题 / 先问重要性,再寻找共性结构
|
||||
|
||||
- 状态:确认
|
||||
- 适用范围:科研选题、问题定义、方法设计与研究方向判断
|
||||
- 规则:先识别真正值得解决的问题,再从具体任务中抽象共性结构,并尽量设计对一类问题有普遍意义的解决方案;具体任务更适合作为理解共性问题的窗口,而不是研究的终点。
|
||||
- 证据:[vibe coding 时代的科研品味](learnings/2026-07-18-001-research-taste-in-vibe-coding.md),[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md),[把奖项看作分布的一次抽样](learnings/2026-07-19-001-how-to-win-a-best-paper-award.md)
|
||||
- 边界:这是用户当前、明确但仍开放修正的工作定义;“好发文章”“可工业落地”“热门”、venue 或奖项都不能单独充当标准答案,抽象也必须有真实理解和科学价值支撑。外部认可可以提供反馈,但受时机、评审偏好和学术权力结构影响。
|
||||
|
||||
### 科研表达 / 用问题—窗口—方法—证据组织故事
|
||||
|
||||
- 状态:确认
|
||||
- 适用范围:论文摘要、研究叙事、proposal、技术报告和结果表达
|
||||
- 规则:先确定一个可用一句话复述的中心 idea,再从重要的共性问题出发,说明具体任务为何是观察该问题的 benchmark、方法如何尝试解决这类问题以及结果提供了什么证据;让段落、图和实验都服务这条主线,而不只报告“方法 A 在任务 B 上得到结果 C”。
|
||||
- 证据:[vibe coding 时代的科研品味](learnings/2026-07-18-001-research-taste-in-vibe-coding.md),[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md),[把奖项看作分布的一次抽样](learnings/2026-07-19-001-how-to-win-a-best-paper-award.md)
|
||||
- 边界:更宏大的叙事不自动意味着更好的研究;问题、benchmark、方法和结果之间必须存在真实联系,不能用包装替代证据。“一个中心 idea”也不等于省略限制、反例、替代解释或会改变 claim 的必要实验。
|
||||
|
||||
### 科研评审 / 重视简洁、内在一致、启发性、必然性与适用范围
|
||||
|
||||
- 状态:确认
|
||||
- 适用范围:研究问题、理论框架、实验结果、方法和抽象的质量判断
|
||||
- 规则:好的研究应尽量简洁而不故弄玄虚,框架具有内在和谐,结果能引出新问题,方法与问题之间显得自然且有说服力,抽象能覆盖一类问题而非单个特例。
|
||||
- 证据:[vibe coding 时代的科研品味](learnings/2026-07-18-001-research-taste-in-vibe-coding.md),[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md)
|
||||
- 边界:这些是启发式判断标准,不是可以机械打分的 benchmark;使用时仍需结合问题重要性、证据和领域语境。
|
||||
|
||||
### 科研价值 / 不以抽象之名贬低实际问题
|
||||
|
||||
- 状态:确认
|
||||
- 适用范围:选题评价、论文评审、对工程型或应用型研究的判断
|
||||
- 规则:区分真正的一般性科学价值与学术权力结构塑造的“高级感”;实际、可落地或具体的问题并不天然低级,应看研究者是否理解得足够深并能提炼出有意义的东西。
|
||||
- 证据:[vibe coding 时代的科研品味](learnings/2026-07-18-001-research-taste-in-vibe-coding.md),[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md)
|
||||
- 边界:这不是否定科学对一般性的追求,而是要求对“高级/低级”的区分保持反思,避免把范式声望当成研究价值本身。
|
||||
|
||||
### 科研阅读 / 从理解走向评价与综合
|
||||
|
||||
- 状态:暂定
|
||||
- 适用范围:论文阅读、文献调研、paper review、研究入门与选题准备
|
||||
- 规则:阅读时先提炼问题与动机、贡献、证据和结论,再检查重要性、有效性、假设与历史语境,最后主动寻找替代解法、反方论证、迁移场景和开放问题;阅读的产物应是自己的判断,而不只是技术细节摘要。
|
||||
- 证据:[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md),[把奖项看作分布的一次抽样](learnings/2026-07-19-001-how-to-win-a-best-paper-award.md)
|
||||
- 边界:并非每篇论文都值得同样深读;可按 awareness、局部使用和准备延伸三个目的分配深度。真正影响当前 claim、实现或实验的论文需下钻到方法与证据细节;建立领域地图后仍要从 first principles 检查社区惯例,避免把独立思考误解为忽略 prior work。
|
||||
|
||||
### 科研发现 / 把异常当作待验证的机制线索
|
||||
|
||||
- 状态:暂定
|
||||
- 适用范围:异常实验结果、复现失败、系统故障、经验研究与新现象判断
|
||||
- 规则:结果不符合预期时,不立即把它归为 bug 或 discovery;先稳定复现并排除实现、测量和基线问题,再通过独立实现、真实样本、sensitivity 与跨场景迁移检验它是否来自可解释的共性机制。
|
||||
- 证据:[vibe coding 时代的科研品味](learnings/2026-07-18-001-research-taste-in-vibe-coding.md),[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md)
|
||||
- 边界:大多数异常仍可能是普通错误、噪声或偶然相关;“异常值得查”不等于“异常值得发表”,一般化必须晚于排错和独立证据。
|
||||
|
||||
### 科研执行 / 先验证最大风险,再决定是否重投入
|
||||
|
||||
- 状态:暂定
|
||||
- 适用范围:研究开项、原型实验、项目组合管理、论文执行与停止条件判断
|
||||
- 规则:先用最小但有效的实验检验最可能失败的关键假设,并预先写清 success、failure 与 kill criteria;核心风险通过且 best-case 结论确有意义后,再围绕唯一中心 idea 为实现完整性和证据严谨性重投入,失败或意义不足时及时停止或降级交付。
|
||||
- 证据:[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md),[把奖项看作分布的一次抽样](learnings/2026-07-19-001-how-to-win-a-best-paper-award.md)
|
||||
- 边界:最小实验必须保留决定结论的 workload、规模和机制,不能因 prototype 失真而错误否定方向;长周期、基础性、复现、负结果和基础设施工作也可能有累积价值。停止或转向还要考虑合作者承诺、学生培养和已有 artifact,并防止用“避免 sunk cost”包装追逐新鲜感。
|
||||
|
||||
### 系统设计 / 先跑通简单闭环,再按真实约束演进
|
||||
|
||||
- 状态:暂定
|
||||
- 适用范围:系统原型、研究实现、复杂工程、架构设计与从论文到生产的迁移
|
||||
- 规则:先区分 Must-Have 与 Nice-to-Have,用最小机制尽快跑通端到端闭环并验证总体方向,再依据测量和真实需求迭代;演进时同时检查正确性、稳定性、扩展性、尾部行为、资源成本和可维护性。
|
||||
- 证据:[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md)
|
||||
- 边界:简单不是目标函数中的唯一维度,也不是牺牲安全、可靠性、兼容性或必要完整性的通行证;快速原型和生产系统承担的约束不同。
|
||||
|
||||
### GPU 服务器评审 / 从端口规格追到业务有效带宽
|
||||
|
||||
- 状态:确认
|
||||
- 适用范围:GPU 服务器通信配置评审、硬件选型与验收、训练和推理网络瓶颈分析
|
||||
- 规则:不要只看“几卡几网”和 NIC 标称速率;依次核算外部 NIC 聚合出口、PCIe 主机侧供给与共享上行、GPU 到 NIC 的 NUMA/PCIe/socket 路径、具体训练或推理通信需求,再用拓扑、NCCL、链路计数器和端到端业务指标验证实际可用能力。
|
||||
- 证据:[GPU 服务器网络配置五步评审法](learnings/2026-07-20-001-gpu-server-network-review.md)
|
||||
- 边界:聚合端口速率是以 bit/s 表示的理论上界,不等于应用有效吞吐;具体合格线依赖 workload、并行策略、规模和目标指标。该流程主要覆盖通信子系统,不能替代对算力、HBM、CPU 内存、存储、功耗、散热、可靠性和运维的评审。
|
||||
|
||||
### 科研培养 / 以独立判断而非论文数量为终点
|
||||
|
||||
- 状态:暂定
|
||||
- 适用范围:导师—学生合作、研究团队建设、研究实习与长期技术培养
|
||||
- 规则:按人的兴趣、能力、阶段和时间定制问题与风险,通过第一手实践、及时而建设性的反馈、同伴协作和逐步放权,最终让学习者能够独立选题、验证、表达和承担判断,而不是只执行论文任务。
|
||||
- 证据:[赵霞研究与系统文章清单](learnings/2026-07-18-004-zhaoxia-research-systems-reading-list.md)
|
||||
- 边界:自主不等于放任,早期学习者通常需要更具体的支持;长期培养也不能以“坚持”为名忽视压力、退出选择、权力不对等或不健康的工作方式。
|
||||
|
||||
### 实验评测 / 自我比较不能代替独立基线
|
||||
|
||||
- 状态:暂定
|
||||
- 适用范围:系统性能评测、论文 evaluation、baseline 选择、性能 claim 审计
|
||||
- 规则:与自己的旧版本或内部变体比较,只能回答“这次改动对自己是否有帮助”;要证明结果的重要性、竞争力或实际价值,还必须选择与 claim 匹配的独立参照,例如公认标准、当前 SOTA、未扰动系统、理论最优值或硬件极限。
|
||||
- 证据:[不要只和自己做 benchmark](learnings/2026-07-18-002-do-not-benchmark-against-yourself.md)
|
||||
- 边界:自我比较对 regression、ablation、组件优化和开发过程仍然有价值;如果 claim 明确只描述内部增量,它可以是充分证据。需要外部基线时,基线类型必须由问题和 claim 决定,不能机械地一律要求同一种 competitor。
|
||||
|
||||
### 模型评测 / 不允许同一组假设闭环自证
|
||||
|
||||
- 状态:暂定
|
||||
- 适用范围:仿真系统、解析模型、调度与资源模型、模型驱动的系统优化
|
||||
- 规则:如果方法建立在一组简化假设上,不能只在编码了同一组假设的模型或模拟器中验证它;至少需要独立数据、不同假设下的 sensitivity,或真实系统的 reality check 来检验结论是否超出模型自身。
|
||||
- 证据:[不要只和自己做 benchmark](learnings/2026-07-18-002-do-not-benchmark-against-yourself.md)
|
||||
- 边界:受控模型和仿真适合隔离机制、做早期探索或计算不可直接实现的上界;问题在于用它们支持现实有效性或泛化 claim,而没有验证关键假设。
|
||||
|
||||
### 性能优化 / 先估算和测量,再决定复杂度预算
|
||||
|
||||
- 状态:暂定
|
||||
- 适用范围:性能设计、热点优化、库代码、系统调优和性能 review
|
||||
- 规则:先判断代码是否位于 hot path、调用规模和目标资源,再用 back-of-the-envelope estimation、profiling 和基准测量定位量级与瓶颈;只有预期收益与实测证据足够时,才为性能支付可读性、复杂度和维护成本。
|
||||
- 证据:[Abseil Performance Hints](learnings/2026-07-18-003-abseil-performance-hints.md)
|
||||
- 边界:这不等于把性能问题全部推迟到 profiling 之后;若更快的设计不显著损害可读性或复杂度,应在最初设计时采用,尤其是广泛复用的 library API。估算中的操作成本只是量级直觉,必须按实际硬件和 workload 校准。
|
||||
|
||||
### 性能优化 / 优先减少总工作与数据移动
|
||||
|
||||
- 状态:暂定
|
||||
- 适用范围:算法选择、数据结构、内存布局、热点循环、并发与低层代码优化
|
||||
- 规则:优化时先寻找更高杠杆的变化:改善算法复杂度,消除不必要工作,批量化或把工作移出热点路径,减少 allocation、copy、cache line 和同步开销;确认这些结构性机会后,再做局部指令级微优化。
|
||||
- 证据:[Abseil Performance Hints](learnings/2026-07-18-003-abseil-performance-hints.md)
|
||||
- 边界:fast path、cache、specialization、紧凑表示和 parallelism 都会交换内存、code size、尾延迟、通用性或维护复杂度;必须在固定 workload 下分别测量,不能把某个 C++ 示例机械推广到所有系统。
|
||||
|
||||
### 性能设计 / 用窄接口保留局部优化空间
|
||||
|
||||
- 状态:暂定
|
||||
- 适用范围:公共 API、library、模块边界、数据所有权和并发接口设计
|
||||
- 规则:优先让模块具有窄而稳定的接口,把数据结构和实现选择封装在内部;提供确有 workload 需求的 bulk、view 或复用型接口,以减少边界穿越、copy、allocation 和 lock 开销,同时避免承诺调用方并不需要、却会永久限制实现的特性。
|
||||
- 证据:[Abseil Performance Hints](learnings/2026-07-18-003-abseil-performance-hints.md)
|
||||
- 边界:API usability、所有权清晰、线程安全和兼容性仍是约束;只有当调用模式和测量表明收益时才扩展性能 API,不能为了潜在优化预先增加公共表面积。
|
||||
|
||||
### AI 协作 / 把稀缺注意力放在判断而非操作上
|
||||
|
||||
- 状态:确认
|
||||
- 适用范围:vibe coding、AI 辅助科研、Agent 的任务分工与输出重点
|
||||
- 规则:充分利用 AI 完成实现、检索和文字处理,但把更多注意力投入问题是否值得解决、哪些文献真正重要、异常结果如何解释、研究故事如何成立,以及什么才算好的输出。
|
||||
- 证据:[vibe coding 时代的科研品味](learnings/2026-07-18-001-research-taste-in-vibe-coding.md)
|
||||
- 边界:操作能力仍是验证想法和形成可靠证据的必要条件;AI 降低操作门槛,不等于实现质量、事实核查或实验正确性可以被忽略。
|
||||
Reference in New Issue
Block a user