Skip to content

reader-context.md

Latest commit

 

History

History
59 lines (44 loc) · 2.92 KB

reader-context.md

File metadata and controls

59 lines (44 loc) · 2.92 KB
Raw

Reader Context

This file is the reader-specific layer for WEIPING_WIKI / Weiping Wiki.

Historical aliases include vipin wiki, vipinknowledge, and vipin-wiki; old references should resolve to the same knowledge system unless a page says otherwise.

It exists so the knowledge base is not only about sources, but also about how Vipin prefers to read, compare, retain, and use knowledge.

Reader Profile

  • Primary reader: Weiping
  • Main working languages: Chinese and English
  • Preferred interaction style: concise but high-signal, with clear structure and durable outputs
  • Preferred knowledge medium: local markdown files that remain inspectable in Obsidian and Git

Current High-Priority Domains

  • large language models
  • recommender systems
  • uncertainty in LLM-based recommendation
  • research workflow design
  • personal knowledge systems

What To Optimize For

  • preserve durable understanding instead of one-off summaries
  • convert repeated questions into reusable pages
  • highlight tradeoffs, contradictions, and missing evidence
  • avoid losing useful analysis inside chat history
  • maintain a clear public/private boundary at all times
  • answer quickly from content-nature maps, then inspect live local projects only when current structure or edits matter

Reader-Specific Preferences

  • comparisons should be explicit and decision-oriented
  • research notes should separate facts, inferences, and open questions
  • important answers should usually be crystallized into the wiki
  • when a topic is controversial, preserve the best counterarguments instead of flattening them
  • research ideation should be ambitious and original, not constrained to stitching together existing project parts
  • when project or research terms are abstract, prefer broad prior-art scanning across mainstream GitHub projects and top paper/project pages before settling on advice
  • synthesize external examples into original mechanisms, tradeoffs, and implementation lessons rather than copying their artifacts
  • when useful, recommend substantial project reframing or redesign instead of only local improvements

Anti-Patterns

  • generic summaries that do not change the structure of the wiki
  • polished prose with weak sourcing
  • cross-links added without real semantic value
  • graph-first design work that distracts from ingest, synthesis, and retrieval
  • "paper idea by collage": combining existing modules without a new mechanism, claim, or experiment
  • over-respecting the current project frame when a stronger research direction requires changing it
  • treating old folder names or stale wiki paths as guaranteed current truth

Long-Horizon Questions

  • how should uncertainty be represented in LLM-based recommendation systems?
  • what research map best organizes Weiping's current recommendation-paper library?
  • which questions deserve their own topic pages versus one-off analyses?
  • what workflows make this wiki genuinely compounding over months, not just days?