Plain-Text Notes and AI: How Non-Technical Users Can Build a Life-Long Personal Knowledge Base

1. The Real Problem: Why Most Knowledge Bases Are Never Used

For non-technical users, failed knowledge management usually falls into three patterns:

• Saving becomes the end of learning. Articles are stored in a read-later list and never opened again. The information stops at “I saw it” and never reaches “I understand it.”
• Categorization is based on intuition. A system starts with neat categories such as “Work / Life / Learning,” but months later becomes “Work / Work 2 / Work Archive / To Do.” As folders get deeper, the cost of filing increases, and the whole structure eventually collapses.
• The tool becomes the trap. Notes are locked in a proprietary format or stored in a cloud app. Migration feels too painful, so users stay with a tool that keeps getting harder to use.

The root problem is not the tool. It is the assumption that a knowledge base is a warehouse. A warehouse only stores things. It does not process them. A usable knowledge base is a workshop: it has an intake point, a processing flow, and useful outputs. The raw data must stay in the user’s hands, and the format must be common enough to remain usable years later. It also needs to be suitable for AI processing.

2. A Portable Technical Foundation: Plain Text + Folders + AI

2.1 Why Plain Text

A personal knowledge base should use Markdown .md plain-text files as the basic unit. The reasons are practical:

• Readability: UTF-8 plain text can be opened by almost any editor, on almost any operating system, from almost any era. There is no risk of “my note app shut down, so my notes are gone.”
• Version control: Plain text can be managed by version-control tools. Every change can be tracked, rolled back, and compared line by line. Deleted content can often be recovered from history.
• Machine-friendly: This is the key point. AI models process plain text much more effectively than screenshots, handwritten scans, or proprietary formats. A plain-text library can be fed to a model at low cost for summarization, extraction, and question answering.
• Zero migration cost: Switching note-taking apps does not require exporting hundreds of files. Copying the folder is enough.

One practical rule: information that arrives with formatting should be moved into text as much as possible. Meeting conclusions should be written into Markdown, not only left in a chat group. Key points from reference materials should be copied into Markdown, not left only as a screenshot. Screenshots can be kept as attachments, but they should not carry the main content.

2.2 Three-Layer Structure: Capture / Processing / Output

Relying only on folders will eventually fail. A better approach is to organize by processing stage:

knowledge/
├── 00_inbox/        # Capture: raw, unprocessed fragments. Enter only; do not edit here.
├── 01_notes/        # Processing: your own understanding, one concept per note.
├── 02_sources/      # Reference materials: excerpts, sources, and links.
├── 03_projects/     # Projects: around a specific goal, such as certification, home renovation, or job change.
├── 04_output/       # Output: articles, proposals, reports, presentations.
├── 90_archive/      # Archive: outdated but still useful as evidence.
└── rules/           # AI collaboration rules and templates.

The inbox is the pressure-release valve of the entire workflow. When capturing, do not think about classification. Just put it in. Organizing is a separate task and should be scheduled separately. Mixing capture and organization is one of the biggest causes of procrastination.

2.3 Use Metadata Instead of Deep Folders

Folders handle broad separation. Fine-grained retrieval should rely on metadata in the file header, usually YAML front matter:

---
title: Three Key Questions for an Employee Exit Interview
date: 2026-08-26
tags: [management, communication, HR]
status: seed # seed → growing → evergreen
source: Chapter 3 of XX Management Practices
related: ["[[Exit Interview Template]]", "[[Performance Conversation Pitfalls]]"]
---

• status records maturity. A newly captured excerpt is seed. A note rewritten in your own words is growing. A note that has been tested through practice and can be referenced repeatedly is evergreen. The real value of a knowledge base comes from the evergreen part.
• related uses double-link syntax to connect notes, creating a network rather than a rigid tree.
• Folder depth should stay within three levels. Deeper than three levels usually means the classification dimension is wrong.

It is also useful to maintain an index.md entry page listing the core notes for each topic. This index acts as the table of contents for the knowledge base and can be the first context provided to AI when asking questions.

3. The Most Important Practice: Write an AI Collaboration Rules File

Many AI-assisted tools come with constraint documents when created. These documents define the model’s role, output format, prohibited actions, and working habits. Their value is often underestimated. They turn “how I want to work with AI” from repeated verbal instructions into an executable project document.

This is especially important for non-technical users. They may not be able to judge whether the model’s output is correct, so they need the certainty of rules.

3.1 What a Rules File Solves

• Reduces repeated explanation: You do not need to say “answer in English, use bullet points, avoid pleasantries, provide evidence” every time.
• Reduces output drift: Without length and structure constraints, the same question may produce three sentences today and three thousand words tomorrow.
• Clarifies boundaries: Which content must not be shared externally, which conclusions must be marked uncertain, and which actions require confirmation first.

3.2 Where to Get Candidate Rules, and How to Judge Them

There are many public experience summaries, templates, and rule suggestions available. The correct approach is not to copy them wholesale, but to let AI review and adapt them. A five-question checklist can help:

1. Does this rule constrain a general habit, such as “state uncertainty when needed,” or a proprietary operation specific to a particular tool?
2. Will I actually encounter the error it is meant to prevent?
3. What prerequisite skills do I need in order to follow it?
4. Will it significantly increase my daily operating steps?
5. If I delete it, what is the worst-case result?

Keep only the rules that can answer “I really need this, and I can execute it.” The shorter the rules file, the higher the chance it will actually be followed.

3.3 Prompt Template for Asking AI to Review Rules

Role: You are a reviewer of knowledge management workflows.
Task: Below is a set of candidate collaboration rules (see rules/candidates.md).
Review each rule to determine whether it is suitable for a non-technical user
who can spend about 30 minutes per day organizing a personal knowledge base.
For each rule, output:
- Number and a brief summary of the original text
- Decision: adopt directly / adopt after rewriting / recommend discarding
- Reasoning from three angles: necessity, executability, and maintenance cost
- If rewritten, provide a concise English version within 40 words
At the end, output a summary table sorted by recommended priority,
and provide an initial draft of 8 to 12 concise rules for my knowledge base.
Constraints: Do not speak in generalities. Do not add new rules beyond the candidate list.
If information is insufficient, say: "Insufficient information; the user needs to provide XX."

3.4 Template for the Rules File Itself

# Knowledge Base Collaboration Rules v1.2
## Role
You are the organizing assistant for this knowledge base. The user is a non-technical individual.
## Files and Formatting
- Write all outputs to `.md` files using UTF-8 encoding.
- Keep each file under 300 lines.
- Every new note must include the `title`, `date`, `tags`, and `status` front matter fields.
- Use no more than three heading levels.
## Processing Rules
- Always include the source and date for excerpts.
- Separate facts from the user's inferences. Prefix inferences with "My judgment:".
- For any conclusion involving numbers, identify the note where the data comes from.
  If there is no evidence in the knowledge base, answer "No supporting evidence in the knowledge base".
## Prohibited Actions
- Do not overwrite existing notes in `01_notes/`. You may add new notes or suggest changes.
- Do not use personal or sensitive information from the knowledge base in examples or external outputs.
- Do not move or delete files without explicit user confirmation.
## Output Style
- Use English, conclusion first, then evidence, no more than 400 words.
- State uncertainty explicitly rather than hiding it with vague language.

The rules file itself should be version-controlled. Every time it changes, increase the version number or file name, and add one line describing the change. Rules that can be traced can be trusted over the long term.

4. Three Daily Workflows

4.1 Capture: Keep Friction as Low as Possible

Use a single intake point, such as only 00_inbox/. Name files with “date-keyword.” A few rough sentences are enough. The test is simple: if recording one note requires opening two apps, the workflow will not survive two weeks.

4.2 Processing: Progressive Summarization

For important materials, read them in four passes:

1. First pass: highlight only. Mark unclear or important sentences.
2. Second pass: compress the highlights into five key points in your own words.
3. Third pass: add “which existing note is this related to?” and write the connection into related.
4. Fourth pass: write one sentence: “If I only remember one thing, what is it?”

The first three steps may take only a few minutes each. The one sentence produced by the fourth step is the part most likely to be reused. Letting AI produce a first draft and then rewriting it yourself is often the most efficient approach.

4.3 Output: Close the Loop with Writing

The quality standard for a knowledge base is not “how many notes do I have?” It is whether the knowledge base can support a real output: a report, a proposal, exam preparation, or a decision about whether to change jobs. Finished outputs should be placed in 04_output/ and linked back to the notes that support them. The dozen or so notes that are referenced most often are your evergreen notes.

5. Retrieval and AI Question Answering

From low cost to higher cost:

• Filename and metadata retrieval: Tags, dates, and status are enough for most daily queries. This costs almost nothing.
• Full-text search: Many local note-taking tools include full-text search, or support generic text-search tools such as grep.
• Semantic search: Convert note text into vectors, store them in a local vector database, ask questions in natural language, retrieve relevant fragments, and then let a large language model organize the answer. This is the common approach for “asking AI about your own notes.” It requires some environment setup, but it does not require internet training or labeled data.

At every level, the context given to AI should be trimmed first. Provide the index page plus 5 to 10 relevant notes found through search, rather than the entire folder. The more focused the context, the more accurate the answer.

6. Security, Privacy, and Backup

• Redact first: Customer lists, identity information, contract terms, health information, and family matters should not go into the main body of the knowledge base. If they must be recorded, use code names and keep the mapping in a separate file.
• Distinguish local processing from cloud calls: When cloud model capabilities are truly needed, upload only redacted fragments. For highly sensitive content, a locally deployed model can be used for summarization and organization.
• Follow the 3-2-1 backup rule: three copies, two types of media, one off-site. A plain-text knowledge base can be synchronized to cloud object storage at low cost. Enabling version control can preserve historical versions over the long term.
• Schedule regular maintenance: Once a month, spend twenty minutes clearing the inbox backlog, fixing broken links, and upgrading growing notes to evergreen. The decay speed of a knowledge base depends on maintenance frequency, not the tool.

7. Common Mistakes

1. Designing a perfect classification system before starting. Folder structure should grow through use. Start with three levels, then split further when needed.
2. Treating excerpts as notes. Copying and pasting ten thousand original passages is less useful than rewriting ten notes in your own words.
3. Making the rules file too long. A model cannot focus if the rules exceed one page, and the user will also be unwilling to maintain it.
4. Chasing full automation. Summarization, archiving, and tagging can be automated. Judging what is worth keeping cannot be automated. That is the only irreplaceable part.

8. A 30-Day Implementation Plan

• Week 1: Create the folder skeleton, choose a comfortable editor, and dump all ideas and excerpts from the past week into inbox. Collect only; do not organize yet.
• Week 2: Clear the inbox backlog. Write 10 notes, each under 200 words, with metadata completed.
• Week 3: Ask AI to review a batch of candidate collaboration rules and produce the first draft of your own rules file. Test retrieval and question answering with three real questions.
• Week 4: Use the knowledge base to complete one real output, such as a long article, a proposal, or a report. Write the result and remaining gaps into index.md, and adjust the next round of rules accordingly.

After one cycle, you will have a knowledge base that is portable, searchable, and usable with AI. Its value does not come from the number of files. It comes from whether it has actually been used more than once. Non-technical users do not need to understand architecture. They only need to turn information into plain text that they can read, edit, back up, and hand to AI.